Markdown Editor

Threat 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 và ISO/IEC 27001Đầy đủISO/IEC 27001:2022 + Amd 1:2024 clauses 6.1.2 c, 8.2 and Annex A (cited only); ISO/IEC 27005:2022; MITRE ATT&CK v20 tactic namesthreatvulnerabilitycatalogue
Mở trong editorTải .md

Cách dùng: Use it before the first risk assessment and keep it live for every workshop. Fill the relevant threat sources first, then prune and extend the threat event and vulnerability examples from your incidents, audits and threat intelligence. The main pitfall is a catalogue copied once from a public list and never updated.

Xem trước

Threat and Vulnerability Catalogue: [Organization name] ISMS

A maintained catalogue of threat sources, threat events and vulnerabilities that risk assessors use to build risk scenarios, so that every assessment starts from the same, current list instead of a blank page. Each entry is linked to ISO/IEC 27001:2022 Annex A controls (by number with a short label) and, for adversarial events, to MITRE ATT&CK Enterprise tactics (names only). It supports risk identification under ISO/IEC 27001:2022 + Amd 1:2024 clause 6.1.2 c and clause 8.2, follows the event-based and asset-based approaches described in ISO/IEC 27005:2022, and takes input from threat intelligence (Annex A control A.5.7). Replace every [bracketed] value and every row marked Example.

Document control

FieldValue
Document IDDOC-ISMS-018
Version[1.0]
Status[Draft / In review / Approved / Superseded]
Owner[@isms-manager]
Approvers/reviewers[@ciso], [@security-operations-lead], [@it-operations-lead]
Last updatedYYYY-MM-DD
Classification[Internal]
Standard and editionISO/IEC 27001:2022 + Amd 1:2024 (clauses 6.1.2 c, 8.2; Annex A); ISO/IEC 27005:2022; ISO/IEC 27002:2022
External taxonomyMITRE ATT&CK Enterprise v20 (October 2026), tactic names only
InputsThreat intelligence procedure (DOC-ISMS-045), incident register (DOC-ISMS-021), vulnerability remediation tracker (DOC-ISMS-072), audit findings register (DOC-ISMS-086)
Used byDOC-ISMS-010, DOC-ISMS-016, DOC-ISMS-017
Number of entries[Sources: 12 / Threat events: 24 / Vulnerabilities: 18]
Next scheduled reviewYYYY-MM-DD

Approvals

RoleNameDecisionDate
ISMS manager[@isms-manager][Prepared]YYYY-MM-DD
CISO or security lead[@ciso][Approved]YYYY-MM-DD
IT or OT operations representative[@it-operations-lead][Reviewed]YYYY-MM-DD

Revision history

VersionDateAuthorChange
1.0 (Example)YYYY-MM-DD[@isms-manager]First issue for the baseline risk assessment
1.1 (Example)YYYY-MM-DD[@isms-manager]Added THR-022 after threat intelligence on data leakage into public AI services; ATT&CK tactic names updated to v20
[x.y]YYYY-MM-DD[@author][Change summary and trigger]

Contents

1. Purpose and scope

The catalogue gives risk assessors a shared, maintained vocabulary of what can go wrong (threat sources and events) and why it could succeed (vulnerabilities and conditions). It makes risk identification under clause 6.1.2 c systematic and repeatable, and means two assessors looking at the same situation reach similar scores (clause 6.1.2 b).

ItemValue
Covers[All information, systems, processes, sites, people and suppliers in the ISMS scope (DOC-ISMS-002)]
Excludes[Pure financial and market risks; product quality defects without a security dimension]
Who may propose entriesAny risk assessor, control owner, security operations analyst or internal auditor
Who approves changesISMS manager; CISO for retirements of adversarial events
Relationship to the registerCatalogue entries are referenced by ID in risk scenarios; the catalogue holds no scores

2. How the catalogue is used

Approach (ISO/IEC 27005:2022)Starting pointHow the catalogue helpsTypical use
Event-basedRisk sources and the events they can cause, at a strategic levelAssessors pick relevant sources (section 4) and events (section 5) and describe the consequences for the businessAnnual cycle, first assessment, management workshops
Asset-basedAssets from the inventory (DOC-ISMS-012), then threats and vulnerabilities per assetAssessors pair events (section 5) with vulnerabilities (section 6) that exist on each assetCritical systems, new services, detailed technical assessments

Workshop routine (Example):

  1. Before the workshop, the facilitator filters the catalogue to the asset types and processes in scope.
  2. Participants confirm which threat events are credible for the scope, add missing ones and say which vulnerabilities exist today.
  3. The facilitator writes each credible combination as a scenario (section 7) and passes it to scoring under DOC-ISMS-010 and the criteria in DOC-ISMS-015.
  4. New entries proposed in the workshop go through the change route in section 9.

3. Structure, fields and identifiers

PrefixEntry typeKey fields
SRC-NNThreat source (who or what causes harm)Type, capability or nature, motivation where adversarial, relevance
THR-NNNThreat event (what happens)Source type, typical targets, ATT&CK tactics (adversarial only), properties affected, related Annex A controls, likelihood drivers
VUL-NNNVulnerability or condition (why it can succeed)Category, threat events that exploit it, related Annex A controls, how it is detected
SCN-NNNScenario (combination used in an assessment)Source, event, vulnerability, asset, consequence, link to risk register ID

Properties use C (confidentiality), I (integrity) and A (availability). Annex A references use the control number with a short label written for this library, consistent with the Statement of Applicability (compliance/statement-of-applicability). ATT&CK references use tactic names from ATT&CK Enterprise v20; check the current version on the MITRE ATT&CK site, because tactic names and counts change between releases (v20 lists 15 Enterprise tactics, with Stealth (TA0005) and Defense Impairment (TA0112) where earlier versions had a single Defense Evasion tactic; map older scenarios accordingly).

4. Threat sources

IDSourceTypeCapability or natureMotivationRelevant? (Example)
SRC-01Organised cybercriminal groupsAdversarial, externalHigh; ransomware and access-broker ecosystemsFinancial gainYes: all tiers
SRC-02State-sponsored or state-aligned actorsAdversarial, externalVery high; persistentEspionage, disruptionYes for Quillmere Group (manufacturing IP); low for others
SRC-03HacktivistsAdversarial, externalLow to moderateIdeology, publicityYes: public-facing websites
SRC-04Malicious insiders (staff, contractors)Adversarial, internalModerate; legitimate accessGrievance, gainYes: all tiers
SRC-05Compromised or malicious suppliersAdversarial, third partyVaries; trusted accessFinancial gain, espionageYes: all tiers
SRC-06Staff errorAccidental, internalEveryday mistakesNoneYes: all tiers
SRC-07Privileged user errorAccidental, internalHigh impact per mistakeNoneYes: all tiers
SRC-08Hardware and software failureStructuralComponent faults, defectsNoneYes: all tiers
SRC-09Supplier and cloud service failureStructural, third partyOutage, insolvency, withdrawal of serviceNoneYes: all tiers
SRC-10Natural hazards and climate-related eventsEnvironmentalFlood, storm, heat, wildfire, earthquakeNoneYes where sites or providers are exposed (see DOC-ISMS-003)
SRC-11Utility failureEnvironmental, structuralPower, cooling, telecommunicationsNoneYes: own sites and colocation
SRC-12Loss of key peopleStructural, internalDeparture, illness, single points of knowledgeNoneYes: especially small organisations

5. Threat events

IDThreat eventSource typeTypical targetsATT&CK tactics (v20, names)C I ARelated Annex A controlsLikelihood drivers
THR-001 (Example)Phishing that captures staff credentials or session tokensSRC-01, SRC-02E-mail, identity provider, SaaS suiteInitial Access, Credential AccessC, IA.6.3 awareness, A.8.5 secure authentication, A.8.23 web filtering, A.5.17 authentication informationVolume of mail, MFA type, training completion
THR-002 (Example)Ransomware encrypts servers and endpointsSRC-01File servers, virtual machines, backupsExecution, ImpactI, AA.8.7 malware protection, A.8.13 backup, A.8.8 vulnerability management, A.5.29 security during disruptionPatch latency, backup isolation, EDR coverage
THR-003 (Example)Password spraying or credential stuffing against internet-facing loginsSRC-01VPN, admin portals, customer portalCredential Access, Initial AccessCA.8.5 secure authentication, A.5.17 authentication information, A.8.16 monitoringExposed logins without MFA, reuse of breached passwords
THR-004 (Example)Exploitation of a vulnerability in a public-facing applicationSRC-01, SRC-02, SRC-03Web applications, APIs, edge devicesInitial Access, ExecutionC, I, AA.8.8 vulnerability management, A.8.26 application security requirements, A.8.29 security testingExposure, time to patch, listing in vulnerability catalogues of known exploitation
THR-005 (Example)Business e-mail compromise leading to payment fraudSRC-01Finance staff, supplier master dataInitial Access, Collection, ImpactIA.6.3 awareness, A.5.3 segregation of duties, A.5.14 information transferPayment approval process, mailbox security
THR-006 (Example)Exfiltration of data by a malicious insiderSRC-04Customer datasets, source code, designsCollection, ExfiltrationCA.6.1 screening, A.5.18 access rights, A.8.12 data leakage prevention, A.8.16 monitoringBreadth of access, offboarding speed, monitoring of bulk export
THR-007 (Example)Accidental disclosure through misaddressed e-mail or public sharing linksSRC-06E-mail, file sharing, collaboration toolsNot applicable (accidental)CA.5.14 information transfer, A.5.12 classification, A.8.12 data leakage preventionDefault sharing settings, labelling
THR-008 (Example)Cloud storage or service exposed by misconfigurationSRC-06, SRC-07Object storage, databases, cloud consolesDiscovery, Collection, Exfiltration (when found by an attacker)C, IA.8.9 configuration management, A.5.23 cloud service use, A.8.16 monitoringInfrastructure as code coverage, posture monitoring
THR-009 (Example)Compromise through a supplier or software supply chainSRC-05Build pipeline, third-party libraries, managed service providersResource Development, Initial AccessC, I, AA.5.19 supplier relationships, A.5.21 ICT supply chain, A.5.22 supplier monitoring, A.8.28 secure codingSupplier access level, dependency management
THR-010 (Example)Regional outage of the cloud service providerSRC-09Production platformNot applicableAA.5.23 cloud service use, A.5.30 ICT readiness, A.8.14 redundancySingle-region design, failover testing
THR-011 (Example)Failure, withdrawal or insolvency of a critical SaaS supplierSRC-09Ticketing, payroll, CRM, identity providerNot applicableA, CA.5.19 supplier relationships, A.5.22 supplier monitoring, A.5.30 ICT readinessConcentration, exit plan, data export capability
THR-012 (Example)Distributed denial of service against public servicesSRC-01, SRC-03Websites, APIs, DNSImpactAA.8.20 network security, A.8.6 capacity management, A.8.14 redundancyUpstream protection, capacity headroom
THR-013 (Example)Misuse of standing administrator privilegesSRC-04, SRC-07Directory, cloud tenant, databasesPrivilege Escalation, PersistenceC, I, AA.8.2 privileged access, A.8.18 privileged utility programs, A.8.15 loggingNumber of standing admins, review frequency
THR-014 (Example)Lateral movement after an endpoint compromiseSRC-01, SRC-02Internal network, serversDiscovery, Lateral MovementC, I, AA.8.22 network segregation, A.8.1 user endpoint devices, A.8.16 monitoringFlat network, local admin rights
THR-015 (Example)Theft or loss of a laptop or mobile deviceSRC-06, SRC-01Laptops, phones, removable mediaNot applicableCA.7.9 assets off-premises, A.8.1 user endpoint devices, A.8.24 cryptographyTravel, remote work, encryption coverage
THR-016 (Example)Hardware or storage failure in an own facilitySRC-08On-premises servers, storage arrays, plant controllersNot applicableA, IA.7.13 equipment maintenance, A.8.13 backup, A.8.14 redundancyEquipment age, maintenance contracts
THR-017 (Example)Fire, flood or extreme weather affecting a siteSRC-10Offices, plants, data centreNot applicableAA.7.5 physical and environmental threats, A.5.30 ICT readiness, A.7.11 supporting utilitiesSite location, climate exposure in DOC-ISMS-003
THR-018 (Example)Power or cooling failureSRC-11Server rooms, colocation, data centreNot applicableAA.7.11 supporting utilities, A.8.14 redundancyGenerator and UPS testing, cooling redundancy
THR-019 (Example)Unauthorised physical entry to secure areasSRC-01, SRC-04Offices, comms rooms, plant control roomsNot applicableC, IA.7.1 physical perimeters, A.7.2 physical entry, A.7.4 physical monitoringTailgating, visitor process
THR-020 (Example)Erroneous change breaks production or corrupts dataSRC-06, SRC-07Applications, infrastructure, databasesNot applicableI, AA.8.32 change management, A.8.31 environment separation, A.8.29 security testingChange volume, automated testing
THR-021 (Example)Disabling or tampering with security tools and logsSRC-01, SRC-04EDR agents, logging pipeline, SIEMStealth, Defense ImpairmentIA.8.15 logging, A.8.16 monitoring, A.8.7 malware protectionTamper protection, log integrity, admin separation
THR-022 (Example)Confidential data entered into public generative AI servicesSRC-06Customer data, source code, contractsNot applicable (accidental)CA.5.10 acceptable use, A.8.12 data leakage prevention, A.5.23 cloud service useApproved AI tools, policy awareness
THR-023 (Example)Unauthorised remote access to an OT control networkSRC-01, SRC-02, SRC-05Plant remote access, engineering workstationsInitial Access, Lateral MovementI, AA.8.22 network segregation, A.8.20 network security, A.8.5 secure authentication, A.5.21 ICT supply chainVendor remote access, IT and OT connectivity
THR-024 (Example)Loss of a key person who alone runs a critical processSRC-12Release process, key management, OT engineeringNot applicableAA.5.37 documented operating procedures, A.5.2 roles and responsibilities, A.6.3 awareness and trainingTeam size, documentation, cross-training

6. Vulnerabilities and conditions

IDVulnerability or conditionCategoryExploited byRelated Annex A controlsHow detected
VUL-001 (Example)Password-only authentication on remote, admin or SaaS accessTechnologyTHR-001, THR-003, THR-013A.8.5 secure authenticationIdentity provider reports, access review
VUL-002 (Example)Internet-facing systems not patched within target timesTechnologyTHR-002, THR-004A.8.8 vulnerability managementVulnerability scans, remediation tracker DOC-ISMS-072
VUL-003 (Example)Staff not trained to recognise phishing and fraudPeopleTHR-001, THR-005, THR-007A.6.3 awareness, education and trainingTraining records, phishing simulation results
VUL-004 (Example)Standing privileged access without periodic reviewProcessTHR-013, THR-014A.8.2 privileged access, A.5.18 access rightsAccess reviews, privileged account inventory
VUL-005 (Example)Endpoint disks not encrypted on some devicesTechnologyTHR-015A.8.24 cryptography, A.8.1 user endpoint devicesMDM compliance report
VUL-006 (Example)Backups reachable from production credentials or not restore-testedTechnology, processTHR-002, THR-016A.8.13 backupBackup restore test log DOC-ISMS-071
VUL-007 (Example)Flat internal network without segmentationTechnologyTHR-014, THR-023A.8.22 network segregationNetwork diagrams, firewall rule review
VUL-008 (Example)Logs not collected centrally or not reviewedTechnologyTHR-006, THR-021A.8.15 logging, A.8.16 monitoringLog source coverage report
VUL-009 (Example)Cloud and server configuration not baselined, drift undetectedTechnologyTHR-008, THR-020A.8.9 configuration managementPosture management findings
VUL-010 (Example)Supplier engaged without security assessment or contract clausesSupplierTHR-009, THR-011A.5.19 supplier relationships, A.5.20 supplier agreementsSupplier register DOC-ISMS-066
VUL-011 (Example)Production in a single region or site without tested failoverTechnologyTHR-010, THR-017, THR-018A.8.14 redundancy, A.5.30 ICT readinessArchitecture review, DR test reports
VUL-012 (Example)No data leakage controls on e-mail, sharing or AI servicesTechnologyTHR-006, THR-007, THR-022A.8.12 data leakage preventionDLP coverage report, sharing audit
VUL-013 (Example)Joiner, mover and leaver steps incomplete or lateProcessTHR-006, THR-013A.5.16 identity lifecycle, A.5.18 access rightsAccess review exceptions, HR and IT reconciliation
VUL-014 (Example)Continuity and recovery plans not testedProcessTHR-002, THR-010, THR-017A.5.30 ICT readiness, A.5.29 security during disruptionExercise records, DR test reports
VUL-015 (Example)Weak change control and shared development and production environmentsProcessTHR-020, THR-009A.8.32 change management, A.8.31 environment separationChange records sample, pipeline review
VUL-016 (Example)Inadequate physical entry control at an office or plantPhysicalTHR-019A.7.2 physical entry, A.7.4 physical monitoringSite walk-through, badge log review
VUL-017 (Example)Legacy OT systems that cannot be patched or run unsupported softwareTechnology (OT)THR-023, THR-016A.8.8 vulnerability management, A.8.22 network segregationOT asset inventory, vendor support status
VUL-018 (Example)Critical procedures undocumented and known by one personPeople, processTHR-024, THR-020A.5.37 documented operating proceduresProcess maturity review, absence test

7. Building risk scenarios

ScenarioSourceEventVulnerabilityAsset or processConsequenceRegister ID
SCN-001 (Example)SRC-01THR-001VUL-001, VUL-003Customer database via staff SaaS accountsCustomer personal data disclosed (C)R-001
SCN-002 (Example)SRC-01THR-002VUL-002, VUL-006Production platform and backupsService unavailable for days, data loss (A, I)R-006
SCN-003 (Example)SRC-06THR-015VUL-005Laptop fleetLocal files with customer extracts exposed (C)R-003
SCN-004 (Example)SRC-09THR-010VUL-011Analytics platform in the primary regionPlatform unavailable beyond contractual service level (A)R-008
SCN-005 (Example)SRC-02THR-023VUL-007, VUL-017Plant control network at one siteProduction stop and safety risk (I, A)R-014

Rules for scenario writing:

  1. One scenario per credible combination; merge combinations that would receive the same treatment and owner.
  2. If no catalogue entry fits, write the scenario anyway and propose the new entry through section 9; do not force a poor match.
  3. Keep the scenario ID in the register so that a catalogue change can be traced to the risks it affects.

8. Operational technology and sector additions

Where the scope includes operational technology (OT), add or adapt entries for:

  • vendor remote access to controllers and engineering workstations (THR-023);
  • unsupported operating systems on control systems that cannot be patched without a plant shutdown (VUL-017);
  • loss of view or loss of control of a process, with safety consequences that use the safety column of the impact scale in DOC-ISMS-015;
  • removable media used to move files into isolated networks;
  • dependence on a small number of engineers (THR-024).

MITRE also publishes ATT&CK for ICS, a separate matrix for industrial control systems. Use its tactic names for OT entries if your team already works with it, and record the version used.

Sector extensions in this library: energy (isms/energy-27019-controls), telecom (isms/telecom-27011-controls), health (isms/health-27799-controls) and IoT (isms/iot-27400-security).

9. Keeping the catalogue current

InputRouteFrequency (Example)
Threat intelligence items (DOC-ISMS-045)Triage log; relevant items become new or updated entriesMonthly, and within 5 working days for urgent advisories
Incidents and near misses (DOC-ISMS-021)Post-incident review proposes entriesAfter each incident review
Vulnerability management (DOC-ISMS-072)Recurring weakness classes become VUL entriesQuarterly
Internal and external audit findings (DOC-ISMS-086)Systemic weaknesses become VUL entriesAfter each audit
Public catalogues of exploited vulnerabilities (for example the CISA Known Exploited Vulnerabilities Catalog) and scoring systems (FIRST CVSS v4.0)Inform likelihood drivers and VUL detectionContinuous through vulnerability management
New ATT&CK releaseTactic names checked and updatedAt each release (MITRE has issued major versions about twice a year, in April and October)

Maintenance rules:

  • Review the full catalogue at least every [12] months, before the annual risk assessment.
  • Retire entries that are no longer credible by setting status "Retired" with a reason; never reuse an ID.
  • Record the source of each new entry (advisory, incident, audit).
  • When an entry changes, list the affected scenarios and tell their risk owners.

10. Size tiers

AspectSmall: Quillmere Analytics Ltd (Example)Medium: Quillmere Health Systems (Example)Large or multi-site: Quillmere Group (Example)
Size of catalogueAbout 30 entries; OT entries removedAbout 45 entries, including clinical data and colocation entriesGroup catalogue of about 80 entries plus plant-specific OT annexes
MaintainerPart-time ISMS manager (0.5 FTE)ISMS manager with the 3-person security teamCISO's security office (14 people); site security coordinators propose additions
Intelligence inputFree advisories, cloud provider bulletins, sector mailing listsCommercial feed plus health sector information sharingCommercial feeds, sector information sharing, OT vendor advisories
Main approachEvent-based for the annual cycleEvent-based plus asset-based for the scheduling platformEvent-based at group level, asset-based per plant and for the data centre
Review frequencyAnnual, plus after incidentsSemi-annualQuarterly at group level

11. Records and evidence

RecordProvesOwnerLocation (Example)Retention (Example)
Approved catalogue versionsSystematic risk identification (6.1.2 c)ISMS managerDocument management system, DOC-ISMS-018All versions for 3 years
Threat intelligence triage logA.5.7 operating and feeding the catalogueSecurity operations leadTicketing system3 years
Change requests for entriesControlled updates with sourcesISMS managerTicketing system3 years
Scenario lists in assessment reportsCatalogue used in assessments (8.2)ISMS managerDOC-ISMS-0173 years
Notifications to risk ownersAffected risks reassessedISMS managerE-mail or ticket records3 years

12. References

ReferenceEdition or versionUse
ISO/IEC 27001:2022 + Amd 1:20243rd edition 2022; Amd 1 2024-02-23Clauses 6.1.2 c, 8.2; Annex A control numbers
ISO/IEC 27002:20223rd editionControl purpose and guidance, including A.5.7 threat intelligence
ISO/IEC 27005:20224th editionEvent-based and asset-based approaches, risk sources
MITRE ATT&CK Enterprisev20, October 2026Tactic names for adversarial events
NIST SP 800-30 Rev. 1, Guide for Conducting Risk AssessmentsSeptember 2012Free reference for threat source types
FIRST Common Vulnerability Scoring SystemVersion 4.0Vulnerability severity input
CISA Known Exploited Vulnerabilities CatalogLive catalogue, checked November 2026Evidence of active exploitation

Related templates: compliance/risk-methodology, isms/isms-risk-appetite-criteria, compliance/risk-register, isms/isms-risk-assessment-report, isms/threat-intelligence-procedure, compliance/asset-inventory, isms/vulnerability-remediation-tracker, security/threat-model, compliance/statement-of-applicability.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (clauses 6.1.2 c and 8.2, Annex A control numbers), ISO/IEC 27002:2022 and ISO/IEC 27005:2022. All entries, descriptions, short control labels and examples are original text written for this template; no ISO or IEC text is reproduced, and you need the official standards to interpret the requirements. MITRE ATT&CK tactic names are cited as names only; ATT&CK is a trademark of The MITRE Corporation. NIST, CISA and FIRST publications are cited by name and version. Check the current editions and versions before use.

Template licence: MIT.

Template liên quan