# Security Monitoring Procedure: [Organization name]

> Procedure for turning logs into timely detection and response: the
> operating model (in-house SOC, managed detection and response, or a
> hybrid), the log sources that feed monitoring, the detection use cases,
> how alerts are triaged and escalated to incidents, how logs are
> protected and retained, and how monitoring performance is measured. It
> supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A controls A.8.15
> (logging) and A.8.16 (monitoring activities, new in 2022), and feeds the
> incident controls A.5.24 to A.5.28, with guidance from ISO/IEC
> 27002:2022. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- This procedure is the "how we watch" document. What each system must
  log, in which format and for how long is set by the security logging
  standard (`security/security-logging-standard`); how a confirmed
  incident is run is set by the incident response plan
  (`compliance/incident-response-plan`, DOC-ISMS-020). Link to them, do
  not copy them.
- Fill section 4 (operating model) and section 7 (triage and service
  levels) first. They decide who looks at an alert at 03:00 on a Sunday,
  which is the first question an auditor and a customer ask.
- Main pitfall: collecting logs nobody reviews. A.8.16 is judged
  on outcomes: would someone notice an intruder and do something about
  it? A SIEM full of data with no use cases, no triage records and no
  tuning does not pass that test.
- Related templates: `security/soc-playbook`, `security/detection-rule-spec`,
  `isms/network-security-standard`, `isms/threat-intelligence-procedure`,
  `isms/incident-register`, `isms/security-event-reporting-procedure`,
  `ops/incident-severity-matrix`, `security/security-metrics-report`.
-->

## Document control

<!-- Guidance: Record the operating model and the MDR contract reference here so readers know at once who monitors. Auditors check approval and review dates. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-064 |
| Version | [1.0] |
| Status | [Draft / In review / Approved] |
| Owner | [@security-operations-lead] ([Security operations lead or ISMS manager]) |
| Approvers / reviewers | [CISO], [Head of IT Operations], [Data protection officer], [MDR service manager, if used] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] (use case details and contact rota: [Confidential]) |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024, Annex A A.8.15 and A.8.16; ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD (at least annually, after a major incident, or when the operating model changes) |
| Operating model | [In-house SOC / MDR / Hybrid] |
| Monitoring hours | [24 x 7 / business hours with on-call] |
| MDR or SOC contract reference | [Contract ID, supplier register entry in DOC-ISMS-066] |
| Related documents | Incident response plan (DOC-ISMS-020), Incident register (DOC-ISMS-021), Security event reporting procedure (DOC-ISMS-023), Threat intelligence procedure (DOC-ISMS-045), Network security standard (DOC-ISMS-063) |

### Approvals

| Role | Name | Signature or record | Date |
|---|---|---|---|
| Owner, security operations | [Name] | [Reference] | YYYY-MM-DD |
| CISO | [Name] | [Reference] | YYYY-MM-DD |
| Data protection officer | [Name] | [Reference] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | Draft after onboarding the first log sources |
| 1.0 | YYYY-MM-DD | [@author] | Approved; use case catalogue, triage service levels and metrics added |

## Contents

1. [Purpose and scope](#1-purpose-and-scope)
2. [Control mapping](#2-control-mapping)
3. [Roles and responsibilities](#3-roles-and-responsibilities)
4. [Monitoring operating model](#4-monitoring-operating-model)
5. [Log sources and coverage](#5-log-sources-and-coverage)
6. [Detection use cases](#6-detection-use-cases)
7. [Alert triage](#7-alert-triage)
8. [Escalation to incidents](#8-escalation-to-incidents)
9. [Baselines, hunting and tuning](#9-baselines-hunting-and-tuning)
10. [Log protection, privacy and retention](#10-log-protection-privacy-and-retention)
11. [Metrics and reporting](#11-metrics-and-reporting)
12. [Size tiers](#12-size-tiers)
13. [Records and evidence](#13-records-and-evidence)
14. [References](#14-references)
15. [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: State what is monitored and what is not, and why. Pitfall: monitoring production but not the identity provider or the SaaS suite, where most account takeovers start. An auditor compares the scope with the asset inventory (DOC-ISMS-012). -->

This procedure describes how [Organization name] detects security events
that may harm information or services, decides quickly whether they
matter, and hands genuine incidents to the incident response process. It
aims to:

- watch the systems, networks, identities and applications whose
  compromise would hurt the organization most, based on the risk
  assessment and the asset inventory (DOC-ISMS-012);
- detect anomalous and malicious behaviour early enough to limit damage;
- triage every alert consistently, with recorded decisions;
- escalate confirmed or suspected incidents without delay;
- protect logs as evidence and handle personal data in them lawfully;
- measure and improve detection coverage and response speed.

The procedure covers every system, cloud tenancy, SaaS service, network
and endpoint inside the ISMS scope (DOC-ISMS-002), and the monitoring
services provided by suppliers. Physical security monitoring (CCTV,
alarms) is covered by the physical security policy (DOC-ISMS-055) and
enters this procedure only when an alarm suggests an information
security event.

## 2. Control mapping

<!-- Guidance: Show the SoA where each control is implemented. Use your own short labels. Auditors check that the SoA justification for A.8.15 and A.8.16 points to real sections. -->

| Annex A control | Short label used here | Where this procedure implements it |
|---|---|---|
| A.8.15 | Logging | Sections 5 and 10, with the security logging standard |
| A.8.16 | Monitoring activities (new in 2022) | Sections 4, 6, 7, 9 and 11 |
| A.8.17 | Clock synchronization | Section 5.3 |
| A.5.24 to A.5.28 | Incident management planning, assessment, response, learning and evidence | Section 8, handing over to DOC-ISMS-020 |
| A.5.7 | Threat intelligence | Section 9, with DOC-ISMS-045 |
| A.6.8 | Information security event reporting | Section 8, with DOC-ISMS-023 |

## 3. Roles and responsibilities

<!-- Guidance: Make clear who watches, who decides and who is woken up. With an MDR provider, write down which decisions the provider may take alone (for example isolating a laptop) and which need your approval. An auditor checks that on-call rotas and contact lists are current. -->

| Role | Responsibilities |
|---|---|
| Security operations lead | Owns this procedure, the use case catalogue and the metrics; approves tuning changes; chairs the monthly monitoring review |
| SOC analyst or MDR analyst (tier 1) | Watches the alert queue, performs first triage, closes false positives with a reason, escalates |
| Senior analyst or incident handler (tier 2) | Investigates escalated alerts, decides whether an incident exists, starts containment within agreed authority |
| Detection engineer | Builds and tests use cases, manages detection content as code, tunes noisy rules |
| On-call engineer (IT or platform) | Provides system access and context out of hours, carries out containment actions |
| Incident manager | Takes over when an incident is declared, under DOC-ISMS-020 |
| Data protection officer | Advises on lawful monitoring of staff and on personal data in logs |
| Log source owners | Keep their systems sending logs, fix ingestion failures within the agreed time |
| MDR provider (if used) | Delivers monitoring under the contract: hours, response times, permitted actions, reporting |

Permitted actions without prior approval *(Example)*: isolate a single
managed endpoint, disable a single user session or token, block a single
external IP or domain on the protective DNS. Actions that affect a
production service, more than [5] users or a customer need approval from
the incident manager or the on-call engineering lead.

## 4. Monitoring operating model

<!-- Guidance: Choose the model honestly. A two-person security team cannot run 24 x 7 monitoring alone; buying MDR is a valid way to meet A.8.16. Questions: which hours are covered, who has the tools, who owns detection content, how fast must an alert be acknowledged? Pitfall: an MDR contract that only emails alerts to a shared mailbox nobody reads at night. -->

| Model | Description | Suits | Watch out for |
|---|---|---|---|
| Managed detection and response (MDR) | A provider runs the SIEM or uses its own platform, monitors 24 x 7, triages and responds within agreed authority | Small organizations, or any organization without staff for round-the-clock cover | Scope of log sources included, permitted response actions, data location, quality of escalations, exit and log ownership |
| Hybrid | In-house team owns the SIEM and detection content in business hours; MDR or on-call covers nights and weekends | Medium organizations with a small security team | Clean handover between shifts, one shared case tool, consistent triage rules |
| In-house SOC | Organization runs the SIEM, detection engineering and 24 x 7 analysts | Large organizations or those with regulatory or customer demands for direct control | Staffing for 24 x 7 (shift cover needs several people per seat), analyst fatigue, tool cost |

Chosen model for [Organization name]: **[Hybrid]** *(Example)*.

| Element | Decision *(Example)* |
|---|---|
| Platform | [Cloud SIEM] owned by [Organization name], with MDR read and response access |
| Hours | Security team 08:00 to 18:00 local time on business days; MDR at all other times |
| Detection content | Owned by the detection engineer, stored as code, MDR may propose rules |
| Case management | One case tool shared with the MDR provider |
| Escalation | MDR phones the on-call incident handler for P1 and P2 alerts |
| Supplier assurance | MDR provider in the supplier register (DOC-ISMS-066) with annual review |

## 5. Log sources and coverage

<!-- Guidance: List the sources that feed monitoring and check every day that they are still sending. A silent source is worse than a noisy one. Pitfall: a firewall that stopped logging after a firmware upgrade and nobody noticed for three months. An auditor samples a source and asks when it last sent data. -->

### 5.1 Source priority

What each system must log is set in the security logging standard
(`security/security-logging-standard`). Monitoring onboards sources in
this order of priority *(Example)*:

1. Identity provider, directory and privileged access tools.
2. Cloud control plane audit logs for production accounts.
3. Endpoint detection and response (EDR) on servers and laptops.
4. Email security and the SaaS productivity suite audit log.
5. Boundary network sources from the network security standard
   (DOC-ISMS-063): firewalls, VPN or ZTNA, protective DNS, web gateway.
6. Source control and CI/CD, secrets management.
7. Production application security events and database audit.
8. OT network sensors, where present.

### 5.2 Source register

| Source ID | Source | Owner | Expected volume *(Example)* | Silence threshold | Status |
|---|---|---|---|---|---|
| LOG-SRC-001 *(Example)* | Identity provider sign-in and admin logs | IT operations lead | 40,000 events per day | 1 hour | Live |
| LOG-SRC-002 *(Example)* | Cloud audit logs, production accounts | Platform lead | 250,000 events per day | 1 hour | Live |
| LOG-SRC-003 *(Example)* | EDR telemetry and detections | IT operations lead | Agent heartbeat per device | 24 hours per device | Live |
| LOG-SRC-004 *(Example)* | Protective DNS | Network owner | 1,200,000 queries per day | 2 hours | Live |
| LOG-SRC-005 *(Example)* | Source control audit log | Engineering manager | 3,000 events per day | 6 hours | Onboarding |

A source that stays silent beyond its threshold raises an alert to the
source owner, who restores it within [1 business day] *(Example)*. The
security operations lead reports monthly on coverage: sources live
against sources required, and devices with a healthy EDR agent against
devices in the asset inventory.

### 5.3 Time synchronization

All in-scope systems synchronize to [approved time sources] so that
events from different sources can be correlated (A.8.17). The SIEM
records both the event time and the ingestion time; a source whose clock
drifts more than [1 second] *(Example)* from the reference is treated as
a source health issue.

## 6. Detection use cases

<!-- Guidance: A use case links a threat to the data that reveals it, the rule that detects it and the playbook that handles it. Start from your risk register and threat intelligence, not from vendor defaults alone. Pitfall: hundreds of enabled vendor rules nobody understands. An auditor asks how a use case was chosen and when it was last tested. -->

Each use case records: ID, threat or risk addressed (risk register
reference, DOC-ISMS-016), MITRE ATT&CK technique where useful, data
sources, detection logic reference (`security/detection-rule-spec`),
severity, playbook (`security/soc-playbook`), owner, date last tested.

| Use case ID | Detects | Sources | Severity | Playbook |
|---|---|---|---|---|
| MON-UC-001 *(Example)* | Sign-in from impossible travel or anonymizing network followed by MFA method change | LOG-SRC-001 | P2 | Account compromise |
| MON-UC-002 *(Example)* | Creation of a new administrator or privileged role assignment outside change windows | LOG-SRC-001, LOG-SRC-002 | P2 | Privilege abuse |
| MON-UC-003 *(Example)* | EDR detection of credential dumping or ransomware behaviour | LOG-SRC-003 | P1 | Malware and ransomware |
| MON-UC-004 *(Example)* | Cloud audit logging disabled or log retention reduced | LOG-SRC-002 | P1 | Cloud logging tampering |
| MON-UC-005 *(Example)* | Mass download or external sharing of files from the productivity suite | Suite audit log | P2 | Data exfiltration |
| MON-UC-006 *(Example)* | DNS lookups to newly registered or known malicious domains from a server zone | LOG-SRC-004 | P2 | Command and control |
| MON-UC-007 *(Example)* | Unexpected source address or volume on the partner file transfer appliance | Firewall logs | P3 | Suspicious network activity |
| MON-UC-008 *(Example)* | Secret or access token committed to a repository | LOG-SRC-005 | P2 | Secret exposure |
| MON-UC-009 *(Example)* | Log source silent beyond its threshold | All sources | P3 | Source health |
| MON-UC-010 *(Example)* | Connection from the corporate zone directly to an OT zone | OT sensors, firewall logs | P1 | IT to OT intrusion |

Rules for the catalogue:

- Every High or Critical risk in the risk register that monitoring can
  detect has at least one use case, or a recorded reason why not.
- New use cases are tested before going live (replay of sample data or a
  safe simulation) and retested at least [annually] *(Example)*.
- Use cases are reviewed when threat intelligence (DOC-ISMS-045) reports
  a relevant new technique, and after each incident.

## 7. Alert triage

<!-- Guidance: Write the steps an analyst follows for every alert and the time limits by priority. Every closure needs a reason code so false positives can be tuned. Pitfall: alerts closed with no note, which leaves no evidence that monitoring took place. An auditor samples closed alerts and checks the decision trail. -->

### 7.1 Priorities and service levels

| Priority | Meaning | Acknowledge within *(Example)* | Triage decision within *(Example)* | Who is notified |
|---|---|---|---|---|
| P1 | Likely active compromise of a critical system, or loss of a key control | 15 minutes, 24 x 7 | 1 hour | On-call incident handler by phone, incident manager |
| P2 | Suspicious activity that could become an incident | 30 minutes, 24 x 7 | 4 hours | On-call incident handler |
| P3 | Policy violation or low-confidence anomaly | 4 business hours | 2 business days | Security team queue |
| P4 | Informational, used for hunting and trend analysis | Not acknowledged individually | Weekly review | None |

Time is measured from alert creation. Align these priorities with the
organization's severity scale (`ops/incident-severity-matrix`) so that an
escalated alert keeps a consistent rating.

### 7.2 Triage steps

1. **Acknowledge** the alert in the case tool and assign it.
2. **Validate**: check that the data is real and complete (source healthy,
   time correct, not a known test).
3. **Enrich**: add asset owner and criticality from the asset inventory,
   user context from the identity provider, threat intelligence on
   indicators, recent changes from the change calendar.
4. **Decide** one outcome: false positive, benign true positive (expected
   activity), true positive needing escalation, or needs more time.
5. **Act**: close with a reason code, escalate under section 8, or apply a
   permitted containment action (section 3) and escalate.
6. **Record** the decision, evidence looked at and actions taken.

```mermaid
flowchart TD
  A["Alert created"] --> B["Acknowledge and assign"]
  B --> C{"Data valid?"}
  C -- No --> D["Close: source issue, raise source health ticket"]
  C -- Yes --> E["Enrich with asset, user, threat and change context"]
  E --> F{"Outcome"}
  F -- "False positive" --> G["Close with reason code, propose tuning"]
  F -- "Benign true positive" --> H["Close with reason code, record expected activity"]
  F -- "True positive" --> I["Permitted containment if needed"]
  I --> J["Escalate as security event (section 8)"]
  F -- "Needs more time" --> K["Keep open, re-check against service level"]
  K --> F
```

### 7.3 Closure reason codes

| Code | Meaning |
|---|---|
| FP-RULE | Rule logic wrong or too broad; tuning ticket required |
| FP-DATA | Source data wrong or incomplete; source health ticket required |
| BTP-CHANGE | Expected activity linked to an approved change |
| BTP-TEST | Authorized test, penetration test or simulation |
| BTP-USER | Confirmed with the user and the manager as legitimate |
| TP-ESC | True positive escalated as a security event |
| DUP | Duplicate of an open case |

## 8. Escalation to incidents

<!-- Guidance: The handover from monitoring to incident response is where time is lost. Say who declares an incident, how fast, and through which channel. With MDR, test the phone escalation path. An auditor traces one escalated alert into the incident register. -->

A true positive becomes a security event report under the security event
reporting procedure (DOC-ISMS-023). The tier 2 incident handler assesses
it against the incident criteria in the incident response plan
(DOC-ISMS-020) and either declares an incident, recorded in the incident
register (DOC-ISMS-021), or records the event as not an incident with the
reason. Possible personal data breaches are flagged at once to the data
protection officer because legal notification clocks may apply (for
example 72 hours to the supervisory authority under GDPR Article 33 where
feasible).

```mermaid
sequenceDiagram
  participant SIEM as SIEM
  participant MDR as MDR analyst
  participant OnCall as On-call incident handler
  participant IM as Incident manager
  participant DPO as Data protection officer
  SIEM->>MDR: P1 alert MON-UC-003
  MDR->>MDR: Triage and isolate endpoint (permitted action)
  MDR->>OnCall: Phone call and case link within 15 minutes
  OnCall->>OnCall: Assess against incident criteria
  OnCall->>IM: Declare incident and open incident register entry
  IM->>DPO: Flag possible personal data breach
  IM-->>MDR: Request further containment and evidence
  MDR-->>IM: Evidence package and timeline
```

Evidence collected during triage (log extracts, EDR timelines, screenshots)
is preserved under the evidence rules of the incident response plan and,
where legal action is possible, recorded in
`security/forensic-evidence-record`.

## 9. Baselines, hunting and tuning

<!-- Guidance: A.8.16 expects you to know what normal looks like. Record baselines for key behaviours, run hunts on a schedule, and tune rules from closure data. Pitfall: tuning by disabling rules. An auditor checks a hunt record and a tuning change with its reason. -->

**Baselines.** For each critical system the detection engineer records
normal patterns that use cases depend on: usual administrator accounts,
usual sign-in countries, normal data transfer volumes, normal working
hours for privileged activity. Baselines are refreshed at least
[every 6 months] *(Example)* and after major changes.

**Threat hunting.** The security team runs a hypothesis-driven hunt at
least [monthly] *(Example)*, choosing hypotheses from threat intelligence
(DOC-ISMS-045), recent incidents and gaps in use case coverage. Each hunt
is recorded with hypothesis, data searched, findings and any new use case.

| Hunt ID | Hypothesis | Data | Result |
|---|---|---|---|
| HUNT-001 *(Example)* | An attacker uses a stolen session token to access the productivity suite from an unmanaged device | Identity provider and suite audit logs, 30 days | No compromise found; new use case MON-UC-011 proposed for token reuse from new device fingerprints |

**Tuning.** Rules with a false positive rate above [80%] *(Example)* over
a month go to the detection engineer. Tuning narrows the rule (exclusions
with expiry, better thresholds, added context) rather than disabling it.
Disabling a use case requires approval from the security operations lead
and a note in the catalogue.

## 10. Log protection, privacy and retention

<!-- Guidance: Logs are evidence and often contain personal data. Protect them from tampering, limit who can read them, and keep them for a set time. Questions: can an administrator delete their own audit trail? Do staff know they are monitored? Pitfall: monitoring staff without telling them or without a legal basis. An auditor checks access to the SIEM and the retention settings. -->

**Integrity and access.** Logs are sent to the central platform as close
to real time as possible and stored so that administrators of the source
systems cannot change or delete them. Access to the SIEM is limited to
named security staff and the MDR provider, uses MFA, and is itself logged
and reviewed [quarterly] *(Example)*. Integrity and protection measures
follow the security logging standard.

**Privacy.** Monitoring is proportionate to the security purpose. Staff
are told through the acceptable use policy (DOC-ISMS-040) and the
employee security handbook (DOC-ISMS-073) what is monitored and why.
Where personal data is processed, the data protection officer confirms
the legal basis and any consultation required with staff representatives
in each country of operation, and a data protection impact assessment is
considered (`compliance/dpia`). Content of communications is not reviewed
in routine monitoring; investigations that need it follow a documented
approval.

**Retention.** Retention periods are set in the security logging
standard (searchable and retrievable periods per log class) and the
retention standard (`data/data-retention-deletion-standard`). Contracts
with customers and laws in the legal register (DOC-ISMS-014) can require
longer periods. Logs under a legal hold are not deleted until the hold is
lifted. With an MDR provider, the contract states who owns the logs,
where they are stored and how they are returned at exit.

## 11. Metrics and reporting

<!-- Guidance: Measure coverage, speed and quality, and report monthly to the ISMS manager and at least yearly to management review. Pitfall: reporting only alert counts, which reward noise. An auditor checks that metrics feed the measurement programme (DOC-ISMS-080). -->

| Metric | Definition | Target *(Example)* |
|---|---|---|
| Source coverage | Required log sources live divided by required log sources | 95% or more |
| EDR coverage | Devices with a healthy EDR agent divided by devices in the asset inventory | 98% or more |
| Use case coverage | High and Critical risks that monitoring can detect with a use case or a recorded reason why not (section 6), divided by those risks | 100% |
| Acknowledge time | Share of P1 and P2 alerts acknowledged within the service level | 95% or more |
| Triage time | Median time from alert to triage decision, P1 and P2 | Under 1 hour |
| False positive rate | False positives divided by alerts triaged by an analyst | Falling quarter on quarter |
| Hunts completed | Hunts recorded against hunts planned | 100% |

Worked month *(Example)*: Quillmere Health Systems, March 2027.

| Item | Count |
|---|---|
| Alerts generated | 1,240 |
| Closed automatically by enrichment rules (known benign) | 860 |
| Triaged by an analyst | 380 |
| False positives among analyst-triaged alerts | 334 |
| True positives among analyst-triaged alerts | 46 |
| True positives escalated that became incidents | 6 |

Checks: 860 + 380 = 1,240 alerts. 334 + 46 = 380 triaged. False positive
rate 334 / 380 = 87.9% overall. The 80% tuning trigger applies per rule:
the three rules above it this month go to the detection engineer. 6 of 46 true positives
(13.0%) became incidents; the other 40 were security events handled
without declaring an incident.

Monthly results go into the ISMS performance report (DOC-ISMS-081) and
the measurement programme (DOC-ISMS-080); trends and major gaps go to
management review.

## 12. Size tiers

<!-- Guidance: Show how monitoring differs with size. These are the library's working tiers, not official definitions. Pitfall: a small company copying an enterprise SOC design it cannot staff. -->

| Topic | Small: Quillmere Analytics Ltd (46 staff, part-time ISMS manager at 0.5 FTE) | Medium: Quillmere Health Systems (320 staff, full-time ISMS manager plus a 3-person security team) | Large: Quillmere Group (2,400 staff, 6 sites in 4 countries, CISO with a 14-person security office) |
|---|---|---|---|
| Operating model | MDR, 24 x 7; ISMS manager reviews the monthly MDR report | Hybrid: security team in business hours, MDR nights and weekends | In-house SOC for IT with an MDR provider for overflow; OT monitoring with plant engineers |
| Platform | MDR provider platform with identity, cloud, EDR and suite logs | Cloud SIEM owned by the organization, MDR access | SIEM with data lake for long retention, SOAR for automation, OT sensors per plant |
| Use cases | 10 to 20, mostly from the MDR provider, mapped to the top risks | 30 to 60, own detection engineering for the scheduling platform | Large catalogue managed as code, per site and per technology, with OT-specific cases |
| Escalation | MDR phones the Head of Engineering Operations | MDR or analyst phones on-call incident handler | SOC shift lead declares incidents under group and site procedures |
| Hunting | Quarterly hunt by the MDR provider | Monthly hunt by the security team | Weekly hunts, threat intelligence team in the security office |
| Reporting | Monthly MDR report to the ISMS manager, yearly to management review | Monthly to the ISMS manager and steering committee | Monthly per site and group dashboard to the CISO, quarterly to the board committee |

## 13. Records and evidence

<!-- Guidance: List what proves monitoring operates. Link each record from the control evidence matrix (`isms/control-evidence-matrix`, DOC-ISMS-033). An auditor asks for a sample of alerts, a use case test, a hunt and the latest metrics. -->

| Record | Proves | Owner | Location | Retention *(Example)* |
|---|---|---|---|---|
| Log source register and daily health report | A.8.15 coverage, section 5 | Security operations lead | [SIEM and document repository] | 1 year |
| Use case catalogue with test dates | A.8.16 detection design, section 6 | Detection engineer | [Detection repository] | Current plus history in version control |
| Alert and case records with closure reason codes | Triage operates, section 7 | SOC or MDR analysts | [Case tool] | 3 years |
| Escalation records linked to incident register entries | Section 8, A.5.25 | Incident handler | Incident register (DOC-ISMS-021) | As set for the incident register |
| Hunt records | Section 9 | Security team | [Document repository] | 3 years |
| Tuning and rule change records | Section 9 | Detection engineer | [Detection repository] | 3 years |
| SIEM access review records | Section 10 | Security operations lead | [Document repository] | 3 years |
| Monthly monitoring metrics and MDR service reports | Section 11 | Security operations lead | [Document repository] | 3 years |
| MDR contract and annual supplier review | Section 4, A.5.22 | Supplier manager | Supplier register (DOC-ISMS-066) | Contract term plus 6 years |

## 14. References

<!-- Guidance: Cite editions exactly and check them at each review. Do not quote standard text. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | 2022, Amd 1 published 2024-02-23 | Annex A A.8.15, A.8.16, A.8.17 and A.5.24 to A.5.28 (cited by number) |
| ISO/IEC 27002:2022 | 2022 | Control guidance and attributes |
| ISO/IEC 27035-1:2023 and 27035-2:2023 | 2023 | Incident management principles and planning |
| NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile | April 2025 | Detection and handover to response |
| MITRE ATT&CK Enterprise | Check the current version at attack.mitre.org | Technique mapping for use cases |
| CIS Controls v8.1 | Check the current release | Control 8 (audit log management) and 13 (network monitoring and defense), cited by number |
| GDPR (Regulation (EU) 2016/679) | As amended | Example of legal limits on staff monitoring and breach notification |

Official pages: ISO/IEC 27001 https://www.iso.org/standard/82875.html,
Amd 1 https://www.iso.org/standard/88435.html, ISO/IEC 27002
https://www.iso.org/standard/75652.html, ISO/IEC 27035-1
https://www.iso.org/standard/78973.html.

Related templates: `security/security-logging-standard`,
`security/soc-playbook`, `security/detection-rule-spec`,
`security/forensic-evidence-record`, `compliance/incident-response-plan`,
`isms/incident-register`, `isms/security-event-reporting-procedure`,
`isms/threat-intelligence-procedure`, `isms/network-security-standard`,
`isms/control-evidence-matrix`, `ops/incident-severity-matrix`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 (including Amd 1:2024) Annex A
controls A.8.15 and A.8.16 and the guidance in ISO/IEC 27002:2022. Only
control numbers are used, with short labels in the style of the
Statement of Applicability; the procedure, use cases, metrics, examples
and guidance are original wording, and no ISO/IEC text is reproduced. ISO
and IEC standards are copyrighted: obtain the official standards from
ISO, IEC or your national standards body to implement and audit them
(https://www.iso.org/standard/82875.html). Check the current edition and
amendments before use. This is a documentation format, not legal advice
on lawful monitoring. Certification decisions belong to the accredited
certification body. Template licence: MIT.