Threat Intelligence Policy Template: Turning Feeds into Decisions and Evidence

Threat intelligence is an ISO/IEC 27001:2022 Annex A control and a common audit finding because organisations subscribe to feeds and advisories but cannot show that anyone analysed them or that anything changed as a result. The control asks organisations to collect and analyse information about threats and produce threat intelligence. This template is the governing policy for that work: who owns it, which sources are used, how intelligence is analysed at strategic, operational and tactical levels, how it is handled and shared, and how it turns into risk register entries, detections and control changes with evidence an auditor can follow. It is written for CISOs, security operations leads and ISMS managers. The full programme method is in the Threat Intelligence Guide, and the requirements process in the Intelligence Requirements Template.

How to use this template

• Replace text in square brackets, such as [Organisation], [Threat intelligence lead] and [monthly], with your own terms and values. Bracketed values are suggested defaults, not external requirements.
• "Must" indicates a mandatory requirement. "Should" indicates a recommended practice where a documented exception may be justified.
• A small organisation without a dedicated team can meet this policy with a named owner, a short source list, national CERT advisories and a monthly review. Section 4.1 allows the lead role to be part-time.
• Keep the source register and requirements list as separate, versioned records so they can change without re-approving the policy.
• Place this policy beneath your Information Security Policy Template.

1. Purpose

This policy sets how [Organisation] collects, analyses, produces, handles and acts on threat intelligence. Its aims are to understand the threats relevant to [Organisation], to use that understanding to choose and adjust controls, to improve detection and response, and to keep evidence that intelligence leads to action, as the ISO/IEC 27001:2022 Annex A threat intelligence control requires.

2. Scope

This policy applies to:

• All threat information received by [Organisation], including commercial and open-source feeds, government and CERT advisories, supplier security notices, sharing communities and internal incident data.
• All intelligence produced by [Organisation], from board briefings to indicator lists.
• Platforms and integrations used to collect, store and distribute intelligence, including threat intelligence platforms, SIEM and EDR integrations and the service accounts and API keys they use.
• All staff and third parties who collect, analyse, receive or share threat intelligence for [Organisation].

3. Roles and responsibilities

4. Policy statements

4.1 Ownership and requirements

1. [Organisation] must name a [Threat intelligence lead], who may hold the role part-time.
2. Intelligence requirements must be documented, approved by [the CISO] and reviewed at least [every 6 months] and after major business change. They must cover the organisation's sector, geographies, critical assets, technology stack, key suppliers and the identity estate.
3. Each requirement must name its consumer (for example the board, security operations or vulnerability management) and the decision it supports.

4.2 Sources

1. Sources must be recorded in [the source register] with owner, type, cost, requirements served, reliability grading and review date.
2. Sources must include at least: [national CERT or cyber agency advisories], supplier and vendor security advisories for technologies in use, a known exploited vulnerabilities list, at least one sector sharing community where available, and internal sources (incidents, detections, phishing reports).
3. Each source must be graded for reliability and each item for credibility, using [the grading scheme], before it drives significant action.
4. Sources must be reviewed at least [annually] and removed if they no longer serve a requirement. See the Threat Intel Feed Evaluation Guide.
5. Collection must be lawful. Staff must not access criminal forums, purchase stolen data or interact with threat actors unless [an approved procedure] authorises it, with legal review.

4.3 Analysis and production

1. Intelligence must be analysed for relevance to [Organisation] before distribution. Raw feed content is not intelligence under this policy.
2. Products must state the confidence of judgements and the sources relied on, and must be relevant, contextual and actionable. See the Threat Intelligence Report Template.
3. Indicators fed into automated controls must have an expiry or review date and must be tested to avoid blocking legitimate services.

4.4 Handling and sharing

1. Intelligence received under the Traffic Light Protocol must be handled according to its label: TLP:RED to named recipients only, TLP:AMBER+STRICT within [Organisation] only, TLP:AMBER within [Organisation] and its clients on a need-to-know basis, TLP:GREEN within the community, TLP:CLEAR without restriction, as defined in FIRST TLP 2.0.
2. Intelligence shared by [Organisation] must carry a TLP label and be approved by [the Threat intelligence lead]. Sharing outside sharing communities must be approved by [the CISO].
3. Shared intelligence must be stripped of personal data and of details that identify customers or confidential systems unless an agreement allows it.
4. Membership of sharing communities must be recorded with the agreement terms. See the ISACs and Information Sharing Communities Guide.
5. Machine-readable exchange should use open standards such as STIX and TAXII. See the STIX and TAXII Guide.
6. API keys and service accounts used by intelligence platforms and integrations must be inventoried, scoped to the minimum needed, stored in [the secrets management tool] and rotated every [12 months] or on staff departure.

4.5 Turning intelligence into action

1. Every intelligence product that recommends action must have a recorded outcome: action taken, accepted risk or no action needed, with reason.
2. Relevant threats must be added to or updated in [the risk register] and considered in the next risk assessment.
3. Operational intelligence must be reviewed by detection engineering for new or improved detections and threat hunts.
4. Exploitation intelligence must update vulnerability prioritisation. Vulnerabilities known to be exploited must be handled under the expedited timelines of the Vulnerability Management Policy Template.
5. Intelligence about leaked credentials, tokens or keys belonging to [Organisation] must be handled as a potential incident and the credentials rotated.
6. Intelligence relevant to an incident must be passed to the incident manager under [the incident response plan].

4.6 Records and evidence

1. [Organisation] must retain intelligence products, distribution records and action records for at least [12 months].
2. The source register, requirements list and this policy must show a review within the last [12 months].

5. Exceptions

1. Exceptions must be requested through [the exception process] with the business reason, compensating controls and an expiry date of no more than [12 months].
2. Exceptions to section 4.2 item 5 (collection) and section 4.4 (sharing) must be approved by [the CISO] after legal review.
3. All exceptions must be recorded in [the risk register].

6. Compliance and monitoring

7. Review and approval

Implementation guidance

The sequence below is NHI Mgmt Group's recommendation.

1. Write the requirements before buying feeds. Five to ten clear requirements tied to decisions will show which sources you need and which subscriptions add nothing.
2. Build the action log from day one. Auditors typically look for evidence that intelligence was collected, analysed, shared with the right people and acted on, including links to the risk register. A simple log of product, date, recipients and outcome answers most of those questions.
3. Start with free, high-value sources. National cyber agency advisories, vendor advisories for your stack and a known exploited vulnerabilities list cover much of what a small organisation needs.
4. Automate tactical indicators carefully. Pilot indicator blocking in alert-only mode, set expiry dates and keep a fast way to remove a false positive.
5. Connect to the ISMS. Add a threat intelligence item to management review and to the risk assessment procedure, so the threat intelligence control is visibly part of how risks are chosen and treated.

Framework mapping

NIST SP 800-150 sets out a similar sequence for sharing: define goals, identify sources, set scope, establish handling and distribution rules, join sharing communities and apply what is learned.

Standards and references

• ISO: ISO/IEC 27001:2022 Information security management systems
• NIST: SP 800-150, Guide to Cyber Threat Information Sharing
• FIRST: Traffic Light Protocol (TLP) 2.0
• NIST: SP 800-53 Rev. 5 (PM-16 Threat Awareness Program, SI-5)

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Threat Intelligence Guide · Intelligence Requirements Template · Threat Intelligence Maturity Model · NHI Threat Intelligence Guide