Template draft. Replace everything in [square brackets] with your own decision,
delete what does not describe what you really do, and approve it through your own document control. It is not legal
advice and does not make an organisation compliant or certified.
1. Purpose
This policy makes sure that the Organisation understands the threats most likely to affect it, and uses that knowledge to improve detection, prevention, risk assessment and response. Intelligence is useful only when it is analysed against the Organisation's own assets and turned into action.
2. Scope
The policy covers the collection, analysis, use and sharing of information about threat actors, their tools and methods, vulnerabilities being exploited, indicators of compromise and campaigns that may affect the Organisation, its customers or its suppliers.
- In scope: strategic, operational and tactical intelligence, from internal and external sources.
- Out of scope: collection of personal data about individuals beyond what is needed to protect the Organisation, and any activity that breaks the law, such as accessing systems of others to gather information.
3. Terms and Definitions
| Term | Meaning |
|---|
| Strategic intelligence | High-level information on trends, actors and motives for management decisions. |
| Operational intelligence | Information on specific campaigns, tools and methods used by attackers against a sector or region. |
| Tactical intelligence | Technical details, such as indicators of compromise, malicious addresses, file hashes and detection rules. |
| Indicator of compromise (IOC) | A technical sign that a system may have been attacked. |
| Traffic light protocol | A labelling scheme that states how widely shared intelligence may be passed on. |
| Intelligence requirement | A question that the Organisation needs answered, such as which actors target our sector. |
4. Roles and Responsibilities
| Role | Responsibilities |
|---|
| Head of IT Security (document owner) | Owns this policy, sets intelligence requirements, approves sources and sharing communities, and reports to management. |
| Threat intelligence analyst | Collects, validates, enriches and analyses information, produces reports and indicators, and tracks actions. |
| Security operations | Loads indicators and detection rules, hunts for threats and reports matches. |
| Vulnerability and patch managers | Use exploit information to set urgency under the Patch Management Policy. |
| Risk manager | Uses intelligence to update threat likelihood in the risk register. |
| Legal and data protection officer | Advise on lawful collection and sharing, including personal data and confidentiality. |
| Management | Uses strategic reports for decisions on investment, risk acceptance and incident response. |
| Activity | Responsible | Accountable | Consulted | Informed |
|---|
| Set intelligence requirements | Head of IT Security | Head of IT Security | Risk manager, system owners | Management |
| Collect and assess sources | Threat intelligence analyst | Head of IT Security | Security operations | Risk manager |
| Produce intelligence reports | Threat intelligence analyst | Head of IT Security | Security operations | Management |
| Load indicators and run threat hunts | Security operations | Head of IT Security | Threat intelligence analyst | System owners |
| Adjust patch priority and risks | Patch manager and risk manager | Head of IT Operations | Threat intelligence analyst | System owners |
| Share with external communities | Threat intelligence analyst | Head of IT Security | Legal, DPO | Management |
5. Policy Statement
5.1 Intelligence requirements and sources
- The Head of IT Security must set and review, at least [every 12 months], the intelligence requirements: the assets, sectors, technologies, regions and threat types that matter most.
- Sources must be chosen by reliability, relevance and timeliness, and each source is graded and recorded in the source register. Information from a single unverified source is not acted on in a way that disrupts business without corroboration.
- Collection must be lawful. Staff must not access systems without permission, buy stolen data, or engage with criminals unless authorised in writing by the Head of IT Security and legal.
| Source type | Examples | Level |
|---|
| National and sector bodies | National CERT advisories, regulator alerts, sector information sharing groups | Strategic, operational |
| Supplier and product advisories | Vulnerability bulletins for products in the asset register | Tactical |
| Commercial and open feeds | Indicator feeds, vulnerability databases, vendor threat reports, security news | Operational, tactical |
| Internal sources | Incident records, logs, phishing reports, honeypots, penetration test results | Operational, tactical |
| Peers and partners | Trusted communities and supplier alerts | Operational |
| Dark web and public sources | Monitoring for leaked credentials and brand abuse, through an approved provider | Operational |
5.2 Analysis and production
- Raw information is validated, de-duplicated, enriched with context and rated for confidence and relevance to the Organisation before it is used or shared.
- The analyst compares each item against the asset register, technology stack and supplier list, and records whether the Organisation is affected, exposed or not affected.
- Products: a daily bulletin of urgent items; a weekly summary for security and IT leads; a monthly threat report with trends and recommended actions; and a quarterly strategic briefing for management.
- Every report states the source, confidence, affected assets, recommended action, owner and due date.
5.3 Use and action
| Intelligence | Action | Owner | Target |
|---|
| Vulnerability exploited in the wild that affects an Organisation asset | Raise emergency patch or compensating control under the Patch Management Policy | Patch manager | Within [24 hours] of confirmation |
| Malicious addresses, domains, hashes | Block at gateways, load in the endpoint and SIEM tools, search logs back [30 days] | Security operations | Within [4 hours] |
| Phishing campaign targeting the sector | Block sender and links, alert staff, run an awareness message | Security operations | Within [4 hours] |
| Actor methods relevant to the Organisation | Create or tune detection rules and run a threat hunt | Security operations | Within [10 working days] |
| Leaked credentials of staff or customers | Force reset, check for misuse, assess notification duty under the Information Security Incident Management Policy | Incident response lead | Within [24 hours] |
| Trend or new threat type | Update the risk register, the testing plan and awareness content | Risk manager | Next quarterly review |
- Indicators are retired or reviewed for expiry after [90 days] unless renewed, to avoid false matches.
- A match to an indicator on the Organisation's systems is treated as a possible incident and handled by the Information Security Incident Management Policy.
5.4 Sharing and confidentiality
- Intelligence is labelled with the traffic light protocol or equivalent, and sharing must respect the label of the source.
- Sharing with external communities, customers or authorities is approved by the Head of IT Security, after removing personal data, customer identities and details that could expose the Organisation, unless legal advises otherwise.
- Reports on the Organisation's own weaknesses are classified as Confidential and distributed on a need-to-know basis.
- Reportable cyber incidents are reported to the authority within [6 hours] of the Organisation noticing them, as set out in the CERT-In Directions of 28 April 2022 [confirm the current requirement].
5.5 Quality and review
- The analyst measures how often intelligence led to an action or detection, the number of false positives, and how long it took from receipt to action.
- Sources that give low value for [two quarters] are dropped. New sources are trialled for [90 days] before adoption.
6. Worked Example
Note. A national sector alert reports that a group is exploiting a flaw in a remote access gateway product, using two named source address ranges. The analyst matches the product against the asset register and finds the Organisation runs it for supplier access. Confidence is high (two independent sources), relevance is high. Within 4 hours security operations blocks the address ranges and searches logs back 30 days, finding no matches. The patch manager treats the flaw as Emergency, and a virtual patch is applied the same day. The risk manager raises the likelihood of remote access compromise in the risk register, and the monthly report lists the action as closed with evidence. The analyst records the source as reliable and keeps the indicators for 90 days.
7. Compliance and Monitoring
| Check | Performed by | Frequency |
|---|
| Review of intelligence requirements and source register | Head of IT Security | [Yearly] |
| Check that actions from reports are completed on time | Threat intelligence analyst | [Monthly] |
| Threat hunt based on current intelligence | Security operations | [Quarterly] |
| Review of expiry and quality of indicators | Security operations | [Quarterly] |
| Internal audit of this policy | Internal audit | [Yearly] |
8. Measures
| Measure | Target |
|---|
| Urgent intelligence items assessed within [4 hours] | [95%] |
| Reports with owner and due date for every action | [100%] |
| Actions closed by due date | [90%] |
| Exploited vulnerabilities on Organisation assets fixed within the emergency deadline | [100%] |
| Threat hunts completed as planned | [100%] |
9. Records and Evidence
- Source register and intelligence requirements, kept while current plus [2 years].
- Intelligence reports, indicator lists with expiry and action tracker, kept [2 years].
- Records of approved sharing with external parties, kept [5 years].
Annexure A: Threat intelligence report
| Field | Entry |
|---|
| Report number and date | |
| Source, grade and confidence | |
| Summary of threat | |
| Assets or suppliers affected | |
| Recommended actions, owners and dates | |
| Sharing label | |
| Follow-up result | |
10. Exception
Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.
11. Enforcement
Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.
12. Review
This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.
ISO/IEC 27001:2022 references
| Reference | Title |
|---|
| A.5.7 | Threat intelligence |
| A.5.6 | Contact with special interest groups |
| A.8.8 | Management of technical vulnerabilities |
| A.8.16 | Monitoring activities |
| A.5.25 | Assessment and decision on information security events |
| 6.1.2 | Information security risk assessment |