# 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*.

<!--
Guidance: How to use this template
- Use it to build a threat intelligence process that is small enough to
  run every week and concrete enough to show an auditor what changed
  because of it. A.5.7 is about producing intelligence and using it, not
  about subscribing to as many feeds as possible.
- Fill section 3 (intelligence requirements) and section 4 (sources)
  first. Without requirements, the team collects everything and acts on
  nothing.
- Main pitfall: a feed subscription with no analysis, no actions and no
  record. Auditors ask "show me a threat you learned about and what you
  did". Keep the intelligence log (section 9) and the action trail.
- Related templates: `isms/authority-special-interest-contacts`
  (sharing groups and CERTs), `isms/isms-threat-vulnerability-catalogue`
  (risk inputs), `compliance/risk-register`,
  `security/vulnerability-management-policy`,
  `isms/vulnerability-remediation-tracker`, `security/detection-rule-spec`,
  `security/soc-playbook`, `isms/security-monitoring-procedure`,
  `security/security-awareness-program`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: The owner is usually the security lead or the ISMS manager. In small organizations the same person may own this procedure and the vulnerability process; say so. -->

| 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](#1-purpose-and-scope)
- [2. Levels of threat intelligence](#2-levels-of-threat-intelligence)
- [3. Intelligence requirements](#3-intelligence-requirements)
- [4. Sources](#4-sources)
- [5. Intelligence lifecycle](#5-intelligence-lifecycle)
- [6. Analysis and prioritisation](#6-analysis-and-prioritisation)
- [7. Dissemination and handling](#7-dissemination-and-handling)
- [8. Actions and integration with ISMS processes](#8-actions-and-integration-with-isms-processes)
- [9. Intelligence log](#9-intelligence-log)
- [10. Feedback and metrics](#10-feedback-and-metrics)
- [11. Roles and responsibilities](#11-roles-and-responsibilities)
- [12. Size tiers](#12-size-tiers)
- [13. Records and evidence](#13-records-and-evidence)
- [14. References](#14-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: Say what decisions the intelligence serves. If nobody can name a decision that would change because of a piece of intelligence, it is noise. -->

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:

1. Know which threats matter most to the organization and keep that view
   current.
2. Act on urgent threats (for example a newly exploited vulnerability in
   an internet-facing product) within the target times in section 6.
3. Feed risk assessments, control selection, detection rules and
   awareness with current threat information.
4. Contribute to and benefit from trusted sharing communities.

## 2. Levels of threat intelligence

<!-- Guidance: ISO/IEC 27002 describes three layers of threat intelligence. Use them to make sure each audience gets a product it can use: executives do not need hash values, and analysts do not need a board paper. -->

| 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

<!-- Guidance: Requirements are the questions the business wants answered. Derive them from the risk register, the asset inventory and the technology stack. Review them every year and after major incidents. Auditors like to see the link from requirement to risk. -->

| 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

<!-- Guidance: Mix free and paid, internal and external. Record why each source exists (which requirement it serves), its reliability, and how it arrives. Sources that never produce a log entry in a year should be dropped. Do not name vendors in this template; name categories and the sources you actually use in your copy. -->

### 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

<!-- Guidance: The lifecycle below is the common intelligence cycle. Keep each step light, but make sure every step leaves a trace in the log. The feedback step closes the loop and shows continual improvement. -->

```mermaid
flowchart LR
  A["1. Direction: requirements PIR"] --> B["2. Collection: sources SRC"]
  B --> C["3. Processing: dedupe, normalise, enrich"]
  C --> D["4. Analysis: relevance, priority"]
  D --> E["5. Dissemination: right audience, TLP"]
  E --> F["6. Action: patch, detect, block, brief"]
  F --> G["7. Feedback: was it useful?"]
  G --> A
```

| 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

<!-- Guidance: Relevance is the first filter: does it affect technology, suppliers, people or data we have? Then urgency. Write clear target times so the on-duty analyst does not need to escalate every decision. Target times are examples; set your own and keep them consistent with the vulnerability management policy. -->

### 6.1 Relevance test

An item is relevant when at least one answer is yes:

1. Does it concern a product, version or service listed in the asset
   inventory (DOC-ISMS-012) or the cloud service register (DOC-ISMS-044)?
2. Does it concern our sector, a region where we operate, or a supplier
   in the supplier register?
3. Does it describe a technique that our current controls or detections
   do not cover?
4. 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

<!-- Guidance: Shared intelligence often comes with sharing restrictions. Use the Traffic Light Protocol (TLP 2.0) labels exactly as published by FIRST and respect labels set by the source. Breaking a sharing rule can get you removed from a sharing group. -->

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

1. Respect the TLP label set by the source. TLP:RED information is not
   forwarded; TLP:AMBER+STRICT stays within the organization.
2. Remove personal data and customer identifiers before sharing outside
   the organization, unless a legal basis and an agreement allow it.
3. Store intelligence according to its classification (DOC-ISMS-042).
4. 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

<!-- Guidance: This is where A.5.7 earns its place. Show the auditor that intelligence changes risks, controls, detections and training. Each action should have a ticket or record ID in the log. -->

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

```mermaid
sequenceDiagram
  participant SRC as Source
  participant AN as Analyst on duty
  participant OPS as IT operations
  participant RO as Risk owner
  participant LOG as Intelligence log
  SRC->>AN: Advisory on exploited vulnerability
  AN->>AN: Relevance test against asset inventory
  AN->>LOG: Record item with priority P1
  AN->>OPS: Urgent alert and emergency change request
  OPS->>AN: Patch applied or mitigation in place
  AN->>RO: Request risk reassessment
  RO->>LOG: Risk updated, item closed
```

## 9. Intelligence log

<!-- Guidance: The log is the main evidence for A.5.7. One row per relevant item, with the action and its record. Irrelevant items do not need a row, but keep the triage count for metrics. -->

| 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

<!-- Guidance: Measure usefulness, not volume. Report metrics to the measurement programme (DOC-ISMS-080). A rising count of feeds is not an achievement; a falling time to act on P1 items is. -->

### 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

<!-- Guidance: In small organizations one person covers several roles. Name a deputy for the analyst on duty, or urgent alerts wait for someone's holiday to end. -->

| 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

<!-- Guidance: A small organization does not need a threat intelligence platform. It needs a few reliable free sources, a weekly triage slot and a log. Scale tooling and depth with size and exposure. -->

| 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

<!-- Guidance: Keep at least two years of the log and briefs so that surveillance auditors can sample across the certification cycle. Map each record to A.5.7 in the control evidence matrix (DOC-ISMS-033). -->

| 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

<!-- Guidance: Verify feed formats and versions on the official sites at each annual review. ATT&CK releases new versions regularly. -->

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