Security logging and monitoring

Template version: 3.0. Type: policy and procedures for acceptance, monitoring and handling gaps. Proposed adoption profile: an organization of approximately 80 people, potentially using an IT provider and MSSP. This does not assert that your tools collect the events described. An internal owner retains decisions about uses, permissions, accepted coverage and risks arising from missing sources.

After adaptation and adoption, “must” and operational instructions become internal requirements within approved scope. Before adoption they remain proposals. Confirm capabilities, contracts and people, then approve parameters and exceptions. This document guarantees neither exhaustive detection, compliance nor automatic evidential status. Hours, frequencies, thresholds and retention require local decisions; no universal values are prescribed.

1. Purpose, scope and approval

Logging must support defined security questions: access, sensitive changes, operations and protection status. Monitoring must connect observations to a person responsible for assessment and action. Accumulating logs without an intended use, controlled access or alert recipient is not demonstrated capability. Distinguish collection, search, detection and response actually available rather than describe them as one interchangeable function.

Scope must cover priority services and dependencies: identity, endpoints, remote access, network, applications, hosting and the collection pipeline. Outsourced services must identify accessible categories, export, licensing, location, responsibilities and contractual limits. Personal or industrial devices need suitable authority and methods. Missing sources must remain visible, together with the investigation questions they prevent the team from answering.

Before the policy takes effect, demonstrate a source through handling of an authorized benign event. Test an outage and a refused access attempt as well. Results must identify missing capability. Adoption must not label an integration operational merely because an agent is installed or a dashboard shows volume. The internal owner must decide whether demonstrated scope is sufficient.

2. Responsibilities and supplier boundaries

Specify who configures a source, checks rejections, receives outage alerts and verifies correction. Contracts must cover data access, return and service termination. Outsourcing monitoring must not remove the organization's ability to understand gaps or recover authorized evidence. Provider statements must be linked to the service and the capabilities actually purchased.

During absence, tasks must be transferred and accepted. If the MSSP does not cover a period, decide who receives urgent signals or explicitly accept that risk. Automation without a recipient must not be described as handling. Test the fallback and retain the result. An escalation number that nobody has tested must remain an unverified dependency in readiness assessment.

3. Build coverage from investigation questions

For each priority service, business and security owners must define questions: which account accessed it, which operation succeeded, which permission changed and which device observed a connection? Link each question to a category, required fields, owner and test event. A list of products does not replace this mapping or demonstrate that the needed data exists.

Distinguish planned source, verified emission, receipt, interpretation and tested detection use. A source that emits while a parser rejects a critical field is not fully operational. The internal owner must approve actual status. Analysts must see the limitation while assessing alerts, rather than only in an administrative document disconnected from their working process.

Priorities must reflect selected risks and resources. Each integration must state enabled and disabled categories, license or cost limits, available history and lost periods. Enabling a category today does not create historical events retroactively. The supplier must confirm export limitations; the organization must decide their effect on planned investigations. Coverage changes require an updated acceptance record.

4. Configure and accept a source

The source owner must provide identifier, version, configuration, technical identity, protocol, destination and maintenance responsibility. Operators must use authorized change, restrict permissions and plan fallback if logging disrupts service. Sensitive systems require testing with their operator; indiscriminately enabling detail incompatible with operation is not an acceptable implementation of this policy.

Generate an identifiable benign event and locate it at available stages: source, collector, storage and search. Compare fields, time, result and origin. Transformations must preserve meaning and a link to original format where needed. Filters and exclusions must be known. Silent rejection must not be presented as nonexistence of the underlying activity.

The acceptance record must identify reviewer, date, scope and reservations. The internal owner explicitly accepts or rejects operation. Rejection must not erase already useful records; state the restricted use permitted. Retest corrections and preserve the previous result. A supplier's declaration must be distinguishable from the organization's reviewed acceptance and any conditions attached to it.

5. Control time and identifiers

Operators must verify coherent clocks and selected time references. Retain event time, time zone or reference, receipt time and known offsets. Configuration must support explanation of conversions and seasonal changes. A clock correction must not silently rewrite the history used in an investigation. Keep source-time uncertainty separate from transport delay.

Compare a known event on the source with its searchable representation. Justify acceptable tolerance by intended use: [TO COMPLETE: reference, tolerance, method]. If exceeded, limit temporal conclusions, inform analysts and correct the cause. A late arrival and an incorrect source clock require different explanations; one must not be used to conceal the other.

Identifiers must remain stable or interpretable: account, endpoint, service, tenant or network context as appropriate. A reused address alone cannot establish a historical endpoint; an account display name does not prove a person. Normalization must preserve unknowns and avoid replacing missing values with assumed identities. Source owners must explain relevant changes to identifiers and their historical interpretation.

6. Protect transport, storage and confidentiality

Select transfer and storage according to sensitivity, possible loss and constraints. Document paths, permissions, technical identities and transport protections. Check whether outage or saturation destroys events, retains them locally or allows retransmission. Claimed capacity must be compared with the chosen operating conditions. Record what happens outside those conditions so analysts understand possible missing periods.

Separate search, export, configuration, administration and deletion permissions. Investigators do not automatically require collector administration. Exceptional access must be named, authorized and withdrawn at completion. Technical accounts must be limited and tracked; a shared administrative account does not provide the same individual attribution as a personal identity. Explain unavoidable limitations rather than claim equivalent traceability.

Do not deliberately collect passwords, private keys, usable cookies or tokens for ordinary investigation context. Minimize unnecessary personal data. Indispensable exceptions must define access, storage and retention with competent functions. Exports, case attachments, backups and local copies require their own restrictions; protection at the source does not automatically protect subsequent copies or recipients.

7. Detect outage, delay and alteration

Monitor the pipeline itself: silent sources, stopped agents, queues, parsing rejections, saturation, space and access errors. Set thresholds per source and purpose rather than import universal values. Normally quiet sources require suitable checks. Missing volume does not always mean failure, and high volume does not establish quality. Operators must explain the expected activity against which they assess health.

Test receipt of outage alerts through a channel not wholly dependent on the failed component. If independence is unavailable, document and compensate for or accept the limitation. Supplier requests must identify possibly lost periods, expected restoration and necessary verification. Restarting a service does not prove that every missing event was recovered.

When alteration is suspected, preserve useful evidence and avoid masking traces through unrecorded repair. An integrity alert alone does not prove malicious intent; authorized changes and errors must also be considered. Separate collection restoration from investigation of its cause. The lead must decide whether the situation requires incident response and record what remains uncertain.

8. Retention, privacy and exceptional preservation

Define retention by category and use with competent functions: investigation needs, current access, any archive, contract and applicable obligations. Justify detail and permissions. This policy sets no universal retention duration. A period offered by a tool does not alone justify retaining every data category for that period. Record the decision and its supporting local assessment.

The lifecycle must include deletion and copies. Test that expired data disappears from relevant locations through available mechanisms without affecting authorized preservation. If a backup cannot support individual deletion, assess that constraint and its treatment. Do not promise immediate erasure that the organization cannot perform. Retain implementation limitations and the authority that accepted their handling.

Exceptional preservation must remain limited to a case and subject to review; it must not become unlimited archiving of all sources. Competent functions decide specific legal constraints. Analysts should reference authorization rather than distribute legal analysis or unnecessary personal details across every ticket. A preservation decision must say who can lift it and how that decision is recorded.

9. Assess and handle alerts

Each scenario must define objective, sources, known conditions, owner, expected evidence and assessment procedure. Analysts must check original events, target, period and coverage before concluding. Seek an authorized explanation and an independent observation. An alert is neither complete proof of an incident nor evidence that containment was executed. The assessment must state which interpretation is supported.

Tuning must explain unnecessary alerts without hiding service coverage. Exclusions require owner, reason, expiry if temporary and regression testing. Falling alert counts may result from failure; they must not be reported as improvement without coverage checks. The internal owner must accept reservations when a scenario is paused, and the working view must show that pause.

10. Fictional coverage and outage scenario

Fictional Atelier Rivage has approximately 80 staff and an outsourced application. Its MSSP receives sign-ins but not permission changes. The register marks partial emission and forbids describing the change scenario as tested. The IT provider enables an authorized category and performs a benign change. This is an exercise, not customer experience or a product capability claim.

Acceptance requires another analyst to explain conclusions possible during partial coverage, locate the reservation and identify who authorizes resumption. They must distinguish wrong source time from delayed arrival. The exercise fails if volume is used to claim every question is covered. Correctly recognizing an unanswerable question is a valid result requiring treatment, not a defect to hide.

11. Usable annexes and adoption test

• ☐ Locate a known sign-in and sensitive operation.
• ☐ Explain missing fields and uncovered periods.
• ☐ Verify source time, zone, receipt and delay.
• ☐ Trigger a benign interruption and obtain ownership.
• ☐ Refuse unauthorized access and check export.
• ☐ Test deletion and authorized preservation without conflating them.
• ☐ Confirm handover and escalation outside genuinely staffed hours.

12. Exceptions, oversight and revision

Exceptions must identify affected purpose, sources, cause, unanswered questions, compensation, owner, decision-maker and expiry. Short retention, missing fields or unexportable sources require explicit assessment. Suppliers must not accept risk alone. At expiry, obtain verified correction or a new decision; silent renewal is prohibited. A waiver records a coverage gap rather than demonstrating that the missing capability exists.

At [TO COMPLETE: body and cadence], report partial sources, lost periods, untested scenarios, exceptional access and expiring waivers. Indicators must state period, population and method. Gaps require assigned tasks and checks. Unknown state must never count as operational to improve the report. The reviewer must be able to identify the next decision from the evidence supplied.

Format, supplier, purpose and responsibility changes require proportionate review and affected acceptance tests. Record author, reason, approver and previous references. Preserve evidence in [TO COMPLETE: repository, access and retention]. The organization must be able to recover approved records and source documentation at contract termination. A replacement provider must receive limitations as well as the list of nominal integrations.

Primary sources and limitations

The ANSSI logging architecture guide, version 2.0, January 2022 addresses time, coverage, transport, permissions and retention, including R3–R6, R9–R17 and R24–R27. NIST SP 800-61 revision 3 provides context for assessment and protection of investigation records.

The proposed matrices, uses, coverage states, roles and scenarios are local choices to approve and test, not product-capability promises. Adapt official recommendations to actual systems and obligations. This document does not replace privacy assessment or the technical expertise required for reliable collection and defensible interpretation.