Security Monitoring Procedure Template (ISO/IEC 27001 A.8.15, A.8.16)

SOC, MDR or hybrid model, log source register and health, detection use cases, alert triage and service levels, escalation to incidents, metrics

SMSI & ISO/IEC 27001CompletISO/IEC 27001:2022 A.8.15, A.8.16 (cited only); ISO/IEC 27002:2022; NIST SP 800-61 Rev. 3security monitoring procedureMis à jour 1 nov. 2026

Ouvrir dans l'éditeurTélécharger .md

Mode d'emploi: Use it when you need to show that logs are watched and acted on under A.8.15 and A.8.16. Fill the operating model and triage service levels first. The main pitfall is collecting logs with no use cases, triage records or tuning.

Aperçu

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.

Document control

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

Purpose and scope
Control mapping
Roles and responsibilities
Monitoring operating model
Log sources and coverage
Detection use cases
Alert triage
Escalation to incidents
Baselines, hunting and tuning
Log protection, privacy and retention
Metrics and reporting
Size tiers
Records and evidence
References
Standard and licence note

1. Purpose and scope

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

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

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

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

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):

Identity provider, directory and privileged access tools.
Cloud control plane audit logs for production accounts.
Endpoint detection and response (EDR) on servers and laptops.
Email security and the SaaS productivity suite audit log.
Boundary network sources from the network security standard (DOC-ISMS-063): firewalls, VPN or ZTNA, protective DNS, web gateway.
Source control and CI/CD, secrets management.
Production application security events and database audit.
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

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

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

Acknowledge the alert in the case tool and assign it.
Validate: check that the data is real and complete (source healthy, time correct, not a known test).
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.
Decide one outcome: false positive, benign true positive (expected activity), true positive needing escalation, or needs more time.
Act: close with a reason code, escalate under section 8, or apply a permitted containment action (section 3) and escalate.
Record the decision, evidence looked at and actions taken.

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

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).

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

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

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

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

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

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

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.

Modèles associés

SMSI & ISO/IEC 27001