What ISO 27001 is really expecting
ISO 27001 does not require a full-time intelligence team or a mini-SOC. What it expects is much simpler: you should be able to show that you monitor relevant threats, assess whether they apply to your environment, take action when needed, and keep records that prove you did it.
In plain English, auditors want to know:
- who reviews threat intelligence
- how your team decides what matters
- what action gets taken when something matters
- how you prove that it happened
Auditor reality:
they are looking for repeatability, not drama. A small, consistent process usually performs better than a large, noisy one.
The Lightweight Threat Intelligence Procedure
1) Purpose
To ensure relevant threat intelligence is reviewed, assessed, and acted upon in a consistent, risk-based way, with records retained as evidence for ISO 27001.
2) Scope
Keep the scope practical and tied to your real risk surface. A lightweight procedure typically applies to the systems and vendors that could materially affect confidentiality, integrity, or availability.
Typical scope includes:
- production systems, cloud services, and business-critical applications
- core vendors and key suppliers
- identity systems, endpoints, and infrastructure components
- vulnerabilities and exploitation trends that could materially affect the business
3) Roles and responsibilities
Keep ownership clear and simple. This is where small programs usually become stronger, because ambiguity disappears.
| Role |
Primary responsibility |
Why it matters |
| Security Lead / vCISO |
owns triage decisions, escalation, and evidence |
keeps the process governed and consistent |
| IT / Cloud Owner |
owns patching and configuration changes |
turns decisions into actual change |
| App / Engineering Owner |
owns code, library fixes, and deployments |
handles app-layer remediation |
| Risk Owner |
approves risk acceptances and exceptions |
keeps business tradeoffs visible and approved |
Auditor-friendly rule:
security does not “do all the fixes.” Security ensures the decisions, owners, and proof exist.
4) Inputs (your threat intel sources)
Keep sources limited and relevant. A lightweight program usually uses five to eight sources, not fifty.
Recommended categories
- cloud provider advisories
- major platform advisories
- vendor and CVE sources
Operational sources
- MDR / SIEM alerts
- critical SaaS notifications
- national or regional cyber alerts
Evidence rule
Maintain a one-page Threat Intel Sources List with source name, owner, and review frequency.
5) Review frequency
You do not need daily threat intelligence activity unless your risk profile truly demands it. What auditors want to see is a cadence that makes sense and is followed consistently.
A practical lightweight cadence
- weekly source review (around 30 minutes)
- immediate review for high-severity or direct emergency alerts
- monthly summary into management review
This is lightweight, defensible, and realistic for most teams.
If your current threat intel process is still just advisories in inboxes, the fastest improvement is not more feeds. It is a simple intake and decision workflow.
6) Triage workflow
This is the heart of the procedure. Every new alert goes through the same decision steps.
Step A: Log the alert
Create one record per alert in your ticketing system or ISMS tracker.
Minimum intake fields
- date and time received
- source link
- affected product or service
- short description or CVE reference
- initial severity if provided
- assigned triage owner
Why it matters: auditors love an intake trail because it proves alerts enter a governed process.
Step B: Applicability check
This should be time-boxed and consistent. A small set of questions is usually enough.
Ask these five questions
- Do we use it?
- Is it exposed?
- Is it exploitable in our setup?
- What is the likely impact?
- Do we already have compensating controls?
- Not applicable — close with evidence
- Applicable — move to action
- Needs investigation — assign with a 24–48 hour deadline
Useful evidence examples:
asset inventory proof, config screenshots, or notes showing the vulnerable feature is disabled or not externally reachable.
Step C: Action decision
Once something is applicable, choose one path only. That keeps the procedure clean and auditable.
Path 1 — Patch and verify
Use when a patch exists and the risk justifies the change.
Evidence required
- change ticket or record
- deployment proof
- verification proof
Path 2 — Mitigate and monitor
Use when patching is not immediate or carries too much operational risk.
Typical mitigations
- disable a feature or module
- restrict access
- apply a WAF rule
- increase monitoring
Use when remediation is not feasible within SLA and the business accepts the tradeoff.
Must include
- business justification
- compensating controls
- expiry date
- named approver
Path 4 — Close as not applicable
Use when you do not run the product or version, or exposure is not present. Keep a short justification and proof.
7) SLAs
The goal is not to panic-patch everything. The goal is to define clear action SLAs that match your risk tolerance.
| Condition |
Example action SLA |
Meaning |
| Critical + exploited + reachable |
24–72 hours |
take action fast: patch, mitigate, or formally accept |
| High + reachable |
7–14 days |
requires scheduled action, not passive backlog |
| Medium |
next patch cycle, such as 30 days |
routine but still governed |
| Low |
backlog or routine update |
track it, don’t ignore it |
Important:
the SLA is for taking action, not only for patching. That makes the procedure far more realistic and auditable.
8) Verification
Verification is the step most teams miss. It is also the step auditors tend to respect most because it proves control effectiveness.
Verification options
- vulnerability rescan result
- version confirmation before and after
- configuration validation
- non-destructive test evidence
Rule:
“patched” is not the same as “closed” until the outcome has been verified.
9) Records and evidence retention
Keep a simple quarterly evidence pack. It does not need to be complicated. It just needs to be complete enough to show that the process operated.
Quarterly evidence pack contents
- alert intake logs
- top applicable alerts and their outcomes
- patch and mitigation evidence
- risk acceptances with expiry dates
- optional KPI snapshot
Retention should align to your ISMS record retention policy, commonly at least the audit-cycle period.
What auditors will ask—and how this procedure answers fast
| Auditor question |
What to show |
Why it works |
| Show me your threat intel process |
procedure document, sources list, recent intake records |
shows governance and repeatability |
| Show me an example where you acted on intel |
alert record, applicability note, action record, verification proof |
connects signal to action and closure |
| Show me something you closed as not applicable |
alert record, inventory or config proof, closure note |
shows your team is filtering intelligently, not guessing |
| What happens when you can’t patch? |
risk acceptance record, expiry date, compensating controls |
proves exceptions are governed, not ignored |
Common mistakes (and the quick fixes)
Too many intel sources
Fix: reduce sources to the ones that matter to your environment.
No applicability evidence
Fix: always capture inventory or configuration proof.
No SLAs
Fix: define action SLAs rather than “patch everything immediately.”
No verification
Fix: close only with proof.
Exceptions live in email
Fix: use formal risk acceptance with expiry.
No reporting
Fix: summarize the quarter into management review.
Next steps
If your threat intel process is currently just advisories in inboxes, you do not need heavier tooling first. You need a lighter, clearer workflow.
Final takeaway
ISO 27001 threat intelligence does not need to look like a security operations center. It just needs to look like a control: relevant inputs, consistent triage, clear action, verification, and retained evidence.
That is what makes the requirement manageable. It also makes the process more useful to the business because teams stop reacting to noise and start making clear, risk-based decisions.
The goal is not to build a SOC. The goal is to prove that relevant threats are reviewed, decisions are made, and the outcomes are evidenced.
Follow Canadian Cyber
Practical cybersecurity + compliance guidance:
