Threat Intelligence Procedure Template (ISO/IEC 27001 A.5.7)
Threat intelligence for A.5.7: strategic, tactical, operational levels, requirements, sources, lifecycle, prioritisation, TLP, actions, log, metrics
उपयोग कैसे करें: Use it to run a threat intelligence process that changes risks, patches, detections and training. Fill the intelligence requirements and the source register first. The main pitfall is a feed subscription with no analysis, no actions and no log to show the auditor.
प्रीव्यू
Threat Intelligence Procedure: [Organization name]
Describes how [Organization name] collects, analyses, shares and acts on information about information security threats, so that risk assessments, controls, detection and awareness reflect the threats the organization actually faces. It supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.5.7 (threat intelligence, new in the 2022 edition), with guidance from ISO/IEC 27002:2022, and feeds clauses 6.1.2 and 8.2 (risk assessment). Replace every
[bracketed]value and every row marked Example.
Document control
| Field | Value |
|---|---|
| Document ID | DOC-ISMS-045 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@security-lead] |
| Approvers/reviewers | [@isms-manager], [@ciso or cto], [@head-of-it-operations] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal; intelligence products marked with TLP labels] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.5.7, 6.1.2, 8.2); ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD (at least every 12 months) |
| Cadence | [Daily triage, weekly summary, quarterly strategic brief] |
| Related records | Intelligence log (section 9), risk register DOC-ISMS-016, vulnerability remediation tracker DOC-ISMS-072 |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Procedure owner | [@security-lead] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| Top management sponsor | [@ciso or cto] | [Approved] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | First draft |
| 1.0 | YYYY-MM-DD | [@author] | Approved for issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |
Contents
- 1. Purpose and scope
- 2. Levels of threat intelligence
- 3. Intelligence requirements
- 4. Sources
- 5. Intelligence lifecycle
- 6. Analysis and prioritisation
- 7. Dissemination and handling
- 8. Actions and integration with ISMS processes
- 9. Intelligence log
- 10. Feedback and metrics
- 11. Roles and responsibilities
- 12. Size tiers
- 13. Records and evidence
- 14. References
- Standard and licence note
1. Purpose and scope
This procedure sets out how threat information is turned into intelligence that supports decisions at [Organization name]. It covers:
- information about threats, threat actors, their methods and their targets that is relevant to the organization's sector, technology and geography;
- information about actively exploited vulnerabilities in technology the organization uses;
- indicators of compromise (IOCs) and detection content;
- sharing intelligence with trusted communities.
It applies to all systems, cloud services and locations within the ISMS
scope (DOC-ISMS-002). Vulnerability scanning and patching are run under
security/vulnerability-management-policy; incident handling under the
incident response plan (DOC-ISMS-020). This procedure supplies inputs to
both and receives feedback from both.
Objectives:
- Know which threats matter most to the organization and keep that view current.
- Act on urgent threats (for example a newly exploited vulnerability in an internet-facing product) within the target times in section 6.
- Feed risk assessments, control selection, detection rules and awareness with current threat information.
- Contribute to and benefit from trusted sharing communities.
2. Levels of threat intelligence
| Level | Question it answers | Audience | Typical products | Horizon |
|---|---|---|---|---|
| Strategic | Which threat actors and trends affect our business, sector and regions, and how is the risk changing? | Top management, steering committee, risk owners | Quarterly threat brief, input to annual risk assessment and management review | Months to years |
| Tactical | Which techniques and tools do relevant actors use, and do our controls cover them? | Security architects, control owners, IT operations | Technique coverage review (for example mapped to MITRE ATT&CK), control improvement proposals | Weeks to months |
| Operational | What specific attack, campaign or exploit is happening now, and what should we do today? | Security operations, IT administrators, incident responders | Alerts, IOC lists, emergency patch notices, detection rules | Hours to days |
3. Intelligence requirements
| Req ID | Intelligence requirement | Driven by | Level | Consumer |
|---|---|---|---|---|
| PIR-001 (Example) | Which ransomware groups target our sector, and which initial access methods are they using this quarter? | RISK-004 ransomware (risk register) | Strategic and tactical | Steering committee, security team |
| PIR-002 (Example) | Is any vulnerability in our internet-facing products being exploited in the wild? | Asset inventory, internet-facing systems list | Operational | IT operations, platform team |
| PIR-003 (Example) | Are our domains, brands or executives being impersonated in phishing campaigns? | RISK-009 credential theft | Operational | Security team, awareness lead |
| PIR-004 (Example) | Are any of our cloud providers or critical suppliers reporting security incidents? | Supplier register DOC-ISMS-066 | Operational | ISMS manager, supplier owners |
| PIR-005 (Example) | Have credentials belonging to our domains appeared in public breach data or criminal markets? | RISK-009 credential theft | Operational | Identity team |
| PIR-006 (Example) | What new legal or regulatory reporting expectations follow from major threat campaigns? | Legal register DOC-ISMS-014 | Strategic | Legal counsel, ISMS manager |
Keep the list short: 5 to 10 requirements is enough for most organizations; a small organization can start with 4 or 5 (section 12).
4. Sources
4.1 Source categories
| Category | Examples | Typical value | Cost |
|---|---|---|---|
| National CERTs and CSIRTs, government agencies | National cybersecurity centre advisories, sector alerts, CISA advisories and the CISA Known Exploited Vulnerabilities (KEV) catalogue | Authoritative alerts on exploited vulnerabilities and campaigns | Free |
| Information sharing and analysis centres (ISACs) and sector groups | Sector ISAC membership, regional sharing groups (see DOC-ISMS-069) | Peer intelligence, sector-specific IOCs, early warnings | Membership fee or free |
| Technology vendors | Security advisories and bulletins from vendors of products in the asset inventory, cloud provider security bulletins | Patches, workarounds, product-specific exploitation notes | Free with the product |
| Vulnerability scoring data | NVD and CVE records, FIRST CVSS v4.0 scores, FIRST EPSS probabilities | Prioritisation data for vulnerabilities | Free |
| Open sources | Security research blogs, conference talks, open IOC feeds, MITRE ATT&CK knowledge base | Technique descriptions, campaign reports | Free |
| Commercial intelligence services | Threat intelligence platform subscriptions, brand and credential monitoring | Curated, enriched intelligence; dark web monitoring | Paid |
| Internal sources | SIEM and EDR alerts, incident records (DOC-ISMS-021), phishing reports from staff, honeypots | Intelligence about attacks on the organization itself | Internal effort |
| Suppliers and customers | Incident notifications under contract, shared alerts | Supply chain threats | Contractual |
4.2 Source register
| Source ID | Source | Category | Requirements served | Delivery | Reliability rating | Owner | Last reviewed |
|---|---|---|---|---|---|---|---|
| SRC-001 (Example) | CISA KEV catalogue | Government agency | PIR-002 | JSON feed, daily automated check against the asset inventory | A, reliable | Platform team | 2026-09-30 |
| SRC-002 (Example) | National CERT advisories | National CERT | PIR-001, PIR-002 | E-mail and RSS | A, reliable | Security lead | 2026-09-30 |
| SRC-003 (Example) | Sector ISAC portal | ISAC | PIR-001, PIR-003 | Portal and TAXII 2.1 feed | B, usually reliable | Security lead | 2026-09-30 |
| SRC-004 (Example) | Cloud provider security bulletins | Vendor | PIR-002, PIR-004 | E-mail and status page | A, reliable | Platform team | 2026-09-30 |
| SRC-005 (Example) | Staff phishing report button | Internal | PIR-003 | Mailbox and ticket | B, usually reliable | Security operations | 2026-09-30 |
| SRC-006 (Example) | Credential exposure monitoring service | Commercial | PIR-005 | Alert e-mail and API | B, usually reliable | Identity team | 2026-09-30 |
Reliability scale (Example): A reliable, B usually reliable, C fairly reliable, D not usually reliable, E unreliable, F cannot be judged. Rate the information separately from the source when needed (confirmed, probably true, possibly true, doubtful).
5. Intelligence lifecycle
| Step | What happens | Who | Output |
|---|---|---|---|
| 1. Direction | Set and review intelligence requirements (section 3) | Security lead with ISMS manager and risk owners | PIR list, annual review record |
| 2. Collection | Receive items from the source register, automated where possible | Security operations, platform team | Raw items in the intelligence mailbox, platform or ticket queue |
| 3. Processing | Remove duplicates, normalise formats (for example STIX 2.1), enrich with asset and exposure data | Security operations | Candidate items |
| 4. Analysis | Decide relevance, confidence and priority (section 6) | Analyst on duty | Log entry with priority |
| 5. Dissemination | Send the right product to the right audience with a TLP label (section 7) | Analyst, security lead | Alert, ticket, weekly summary, quarterly brief |
| 6. Action | Owners act: patch, block, add detection, update risk, brief staff (section 8) | Control owners | Change, ticket, risk update |
| 7. Feedback | Consumers rate usefulness; metrics reviewed (section 10) | Security lead | Feedback record, source changes |
6. Analysis and prioritisation
6.1 Relevance test
An item is relevant when at least one answer is yes:
- Does it concern a product, version or service listed in the asset inventory (DOC-ISMS-012) or the cloud service register (DOC-ISMS-044)?
- Does it concern our sector, a region where we operate, or a supplier in the supplier register?
- Does it describe a technique that our current controls or detections do not cover?
- Does it mention our domains, brands, staff or customers?
6.2 Priority levels
| Priority | Criteria | Target time to first action (Example) | Example action |
|---|---|---|---|
| P1 Urgent | Active exploitation of a relevant vulnerability on an internet-facing system (for example listed in CISA KEV or confirmed by a CERT), or an active campaign naming the organization | 24 hours | Emergency change, temporary block, threat hunt, executive notice |
| P2 High | Exploitation likely (for example high EPSS probability or public exploit code) for a relevant internal system, or a campaign targeting our sector | 7 days | Planned patch, detection rule, targeted awareness message |
| P3 Medium | Relevant technique or trend with no immediate exposure | 30 days | Control review, risk register update |
| P4 Information | Background or strategic context | Next quarterly brief | Include in strategic brief |
Where intelligence concerns a vulnerability, the priority above sets the deadline in the vulnerability remediation tracker (DOC-ISMS-072) and overrides a lower priority derived from CVSS alone. CISA SSVC decision trees can support this decision if the team already uses them.
6.3 Confidence
Record confidence in the assessment as High, Moderate or Low, based on source reliability, corroboration from a second source and how directly the item applies to the organization. Low-confidence P1 items are still acted on, with a note to re-check.
7. Dissemination and handling
| Product | Audience | Frequency (Example) | Format | Default TLP |
|---|---|---|---|---|
| Urgent alert | IT operations, affected system owners, incident manager | As needed (P1) | Ticket plus chat message | TLP:AMBER |
| Weekly threat summary | Security team, IT leads, ISMS manager | Weekly | One page | TLP:AMBER |
| IOC and detection package | SOC, detection engineers | As needed | Machine-readable (STIX 2.1 or CSV) | Per source label |
| Quarterly strategic brief | Steering committee, risk owners | Quarterly | 2 to 4 pages | TLP:AMBER |
| Awareness note | All staff | Monthly or as needed | Intranet post or e-mail | TLP:CLEAR |
| Sharing contribution | ISAC or sharing group | As needed | Community format | TLP:GREEN or TLP:AMBER |
Handling rules:
- Respect the TLP label set by the source. TLP:RED information is not forwarded; TLP:AMBER+STRICT stays within the organization.
- Remove personal data and customer identifiers before sharing outside the organization, unless a legal basis and an agreement allow it.
- Store intelligence according to its classification (DOC-ISMS-042).
- Before contributing to a sharing group, the security lead checks that the contribution does not reveal confidential information about ongoing incidents, customers or legal matters.
8. Actions and integration with ISMS processes
| ISMS process | How threat intelligence feeds it | Record |
|---|---|---|
| Risk assessment (6.1.2, 8.2) | Strategic brief updates likelihood ratings and adds new scenarios; P1 and P2 items can trigger an out-of-cycle reassessment | Risk register DOC-ISMS-016, threat catalogue DOC-ISMS-018 |
| Control selection and SoA (6.1.3) | Technique coverage gaps lead to new or improved controls | Risk treatment plan DOC-ISMS-013 |
| Vulnerability management (A.8.8) | Exploitation data raises priorities and sets deadlines | Vulnerability remediation tracker DOC-ISMS-072 |
| Monitoring and detection (A.8.16) | IOCs and technique reports become detection rules and hunts | Detection rule specification (security/detection-rule-spec), monitoring procedure DOC-ISMS-064 |
| Network and web filtering (A.8.20, A.8.23) | Malicious domains and IPs added to block lists with an expiry | Block list change record |
| Incident management (A.5.24 to A.5.28) | Context for triage, attribution and scoping; incidents produce internal intelligence | Incident register DOC-ISMS-021 |
| Awareness (A.6.3) | Current phishing lures and scams used in training and simulations | Awareness programme, phishing simulation plan DOC-ISMS-074 |
| Supplier management (A.5.19 to A.5.22) | Supplier breach reports trigger supplier reviews | Supplier register DOC-ISMS-066 |
| Management review (9.3) | Quarterly brief summarised as an input on changes in external issues | Management review minutes DOC-ISMS-085 |
9. Intelligence log
| TI ID | Date received | Source | Summary | Requirement | Priority | Confidence | Affected assets | Action and record | Owner | Closed |
|---|---|---|---|---|---|---|---|---|---|---|
| TI-2027-001 (Example) | 2027-01-08 | SRC-001 CISA KEV | Remote code execution in the VPN appliance model used at two offices, exploited in the wild | PIR-002 | P1 | High | Two VPN gateways | Emergency change CHG-2027-004, patched within 18 hours, hunt found no compromise | Platform team | 2027-01-09 |
| TI-2027-002 (Example) | 2027-01-15 | SRC-003 ISAC | Phishing campaign against the sector impersonating a payroll provider | PIR-003 | P2 | Moderate | All staff mailboxes | Mail filter rule MFR-112, awareness note to all staff, used in February simulation | Security operations | 2027-01-17 |
| TI-2027-003 (Example) | 2027-01-22 | SRC-002 National CERT | Ransomware group shifting to abuse of remote management tools | PIR-001 | P3 | Moderate | Endpoints with remote support tools | Detection rule DET-045, risk RISK-004 likelihood reviewed (unchanged at 3) | Security lead | 2027-02-10 |
| TI-2027-004 (Example) | 2027-02-03 | SRC-006 credential monitoring | 3 staff credentials found in a third-party breach dataset | PIR-005 | P2 | High | 3 user accounts | Passwords reset, sessions revoked, MFA confirmed, users informed | Identity team | 2027-02-03 |
| TI-2027-005 (Example) | 2027-02-11 | SRC-004 cloud provider | Provider reports a service incident in a managed database service in a region not used by the organization | PIR-004 | P4 | High | None | No action, noted in weekly summary | Platform team | 2027-02-11 |
10. Feedback and metrics
10.1 Feedback
After each P1 action and each quarterly brief, the consumer answers three questions: Was it relevant? Was it timely? Did it lead to an action? The security lead reviews the answers quarterly and adds, tunes or removes sources.
10.2 Metrics
| Metric ID | Metric | Target (Example) | Source |
|---|---|---|---|
| TI-M01 | Median time from receipt to first action for P1 items | 24 hours or less | Intelligence log |
| TI-M02 | Share of P1 and P2 items with a recorded action and record ID | 100% | Intelligence log |
| TI-M03 | Number of risk register updates triggered by intelligence per quarter | At least 1 | Risk register history |
| TI-M04 | Number of detection rules created or tuned from intelligence per quarter | At least 2 | Detection rule records |
| TI-M05 | Share of sources that produced at least one relevant item in 12 months | 80% or more | Source register |
| TI-M06 | Contributions made to sharing groups per year | At least 2 | Sharing records |
Worked example (Example): in the first quarter of 2027 the team logged 5 relevant items (TI-2027-001 to TI-2027-005): 1 P1, 2 P2, 1 P3 and 1 P4. All 3 P1 and P2 items had a recorded action (TI-M02 = 100%). The single P1 item was actioned in 18 hours (TI-M01 met).
11. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Security lead (procedure owner) | Owns this procedure, the requirements and the source register; produces the quarterly brief; manages sharing group membership |
| Analyst on duty | Daily triage, relevance and priority decisions, log entries, urgent alerts |
| IT operations and platform team | Act on operational intelligence: patches, blocks, configuration changes |
| Detection engineers or SOC | Turn IOCs and techniques into detections and hunts |
| Risk owners | Update risks when intelligence changes likelihood or impact |
| ISMS manager | Ensures intelligence reaches risk assessment and management review; checks evidence |
| Awareness lead | Uses current threats in training and simulations |
| Legal counsel | Advises on sharing personal data and on legal limits of intelligence collection |
12. Size tiers
| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Staffing | ISMS manager (0.5 FTE, Head of Engineering Operations) runs full triage twice a week with an engineer as deputy; the automated daily KEV check alerts the on-call engineer so P1 items still meet the 24-hour target | One analyst in the 3-person security team owns triage, rotating deputy | Dedicated intelligence function within the 14-person security office, regional contacts at each site |
| Sources (Example) | CISA KEV automated check, national CERT, cloud provider bulletins, vendor advisories for about 15 key products | Adds health sector ISAC, credential monitoring, EDR vendor intelligence | Adds commercial intelligence platform, OT-specific advisories for plant control systems, ISACs in 4 countries |
| Tooling | Shared mailbox, ticket queue, spreadsheet log | Ticketing integrated with SIEM, IOC import into EDR | Threat intelligence platform with STIX and TAXII, automated enrichment, SOC integration |
| Products | Weekly summary of half a page, quarterly brief to the CTO | Weekly summary, monthly awareness note, quarterly brief to the steering committee | Daily operational digest, weekly regional summaries, quarterly board-level brief, OT bulletins for plants |
| Requirements | 4 to 5 PIRs tied to platform and credential risks | 6 to 8 PIRs including healthcare customer threats | 10 or more PIRs per business line, including OT and supply chain |
| Sharing | Receives only, at first | Receives and contributes to the sector ISAC | Active member of several ISACs, contributes regularly |
13. Records and evidence
| Record | Proves | Owner | Location | Retention (Example) |
|---|---|---|---|---|
| Intelligence requirements (PIR list) with review date | Direction is set and reviewed | Security lead | [ISMS document repository] | Current plus previous 2 versions |
| Source register | Sources are chosen, rated and reviewed | Security lead | [Repository] | Current plus 2 years |
| Intelligence log | Items are analysed, prioritised and acted on | Analyst on duty | [Ticket system or log file] | 3 years |
| Weekly summaries and quarterly briefs | Intelligence is disseminated to the right audiences | Security lead | [Repository] | 3 years |
| Action records (changes, tickets, detection rules, risk updates) | Intelligence leads to action | Control owners | [Change and ticket systems] | Per the owning process |
| Feedback and metrics reports | The process is evaluated and improved | Security lead | [Measurement programme records] | 3 years |
| Sharing group memberships and agreements | Sharing is authorised and rules are known | Security lead | DOC-ISMS-069 | Life of membership plus 1 year |
Reference this procedure in the Statement of Applicability (DOC-ISMS-011)
against A.5.7 and list the records in isms/control-evidence-matrix.
14. References
| Reference | Edition or version (checked 2026-11-01) | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.html | Current | A.5.7, clauses 6.1.2 and 8.2 |
| ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | Current | Guidance on strategic, tactical and operational intelligence |
| ISO/IEC 27005:2022, https://www.iso.org/standard/80585.html | Current | Use of threat information in risk assessment |
| CISA Known Exploited Vulnerabilities catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog | Live catalogue, CSV and JSON | Exploited vulnerability source |
| FIRST CVSS v4.0, https://www.first.org/cvss/ | Published November 2023 | Vulnerability severity scoring |
| FIRST EPSS, https://www.first.org/epss/ | Daily scores, free | Exploitation probability |
| FIRST Traffic Light Protocol 2.0, https://www.first.org/tlp/ | August 2022 | Sharing labels |
| MITRE ATT&CK, https://attack.mitre.org/ | v20.0 (October 2026); check for newer versions | Technique taxonomy for tactical intelligence |
| OASIS STIX 2.1 and TAXII 2.1 | OASIS Standards, June 2021 | Exchange formats |
| NIST CSF 2.0 (CSWP 29) | February 2024 | ID.RA outcomes on threat intelligence (optional mapping) |
| Related templates | isms/authority-special-interest-contacts, isms/isms-threat-vulnerability-catalogue, compliance/risk-register, security/vulnerability-management-policy, isms/vulnerability-remediation-tracker, security/detection-rule-spec, security/soc-playbook, isms/security-monitoring-procedure, isms/phishing-simulation-plan, isms/control-evidence-matrix |
Standard and licence note
Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control A.5.7 and clauses 6.1.2 and 8.2), ISO/IEC 27002:2022 and ISO/IEC 27005:2022. Control and clause numbers are cited with original short labels; the procedure text, tables and examples are original, and no text from ISO/IEC standards is reproduced. Obtain the official standards from ISO, IEC or your national standards body. CISA, FIRST, MITRE, OASIS and NIST materials are cited by name and version only. Check the current edition or version of each reference before use.
Template licence: MIT.
संबंधित टेम्पलेट
Information Labelling and Handling Procedure Template (ISO/IEC 27001)
Label texts and formats, handling matrix from create to destroy per class, e-mail and file label settings, auto-labelling, paper and media, TLP mapping
ISMS और ISO/IEC 27001Threat and Vulnerability Catalogue Template (ISO/IEC 27005, ATT&CK)
12 threat sources, 24 threat events and 18 vulnerabilities linked to Annex A controls and ATT&CK v20 tactics, scenario building, OT entries, update route
ISMS और ISO/IEC 27001Personnel Screening Procedure Template (ISO/IEC 27001 A.6.1)
Risk-based screening levels S1 to S3, role mapping, check catalogue, jurisdiction table, adverse findings, contractors, re-screening, retention