Finding template library
pre-written vulnerabilities ready to log
A built-in catalogue of pre-written finding templates covering common web, infrastructure, AppSec, and configuration vulnerabilities for pentests, plus dedicated template sets for Cyber Essentials, Cyber Essentials Plus, ISO 27001 Annex A, SOC 2 Trust Services Criteria, and incident response engagements. Every template carries a title, description, remediation guidance, and where applicable a CVSS 3.1 vector and a control reference so the operator drops a high-quality finding onto the engagement in seconds rather than typing it from scratch.
No credit card required. Free plan available forever.
A built-in catalogue of pre-written finding templates
Every security engagement produces findings. Pentests produce vulnerability findings. Cyber Essentials assessments produce per-control gap findings against the NCSC scheme. ISO 27001 internal audits produce Annex A coverage findings. SOC 2 readiness sprints produce Trust Services Criteria findings. Incident response engagements produce per-incident findings under time pressure. Each of these engagement types has a well-defined vocabulary the report reader, the certification body, the audit reader, the leadership readout, or the regulator expects, and authoring that vocabulary from scratch on every engagement is the slowest path to a consistent workspace voice.
The finding template library is a built-in catalogue of pre-written templates covering the most common vulnerability classes, configuration gaps, compliance control objectives, and incident classes. Every template carries a title, a canonical description, remediation guidance, a starting severity (where the cohort uses severity), a control reference (where the cohort uses one), and where applicable a CVSS 3.1 vector that seeds the auto-scoring on the finding record. The picker opens on the engagement, filters to the cohort matching the engagement type, supports search and category filters, and applies the template to the finding form in one click. The operator edits the evidence and the asset rather than the writeup.
Five cohorts shaped by the engagement type
The library is organised into cohorts so the picker never mixes unrelated templates. The cohort that opens depends on the engagement type on the parent engagement record.
Pentest, vulnerability assessment, bug bounty, security review, other
Coverage. Web, infrastructure, AppSec, configuration, identity, and cryptography vulnerabilities
Severity model. Severity calibrated per template (critical, high, medium, low) with CVSS 3.1 vectors
Representative templates. SQL injection, reflected and stored cross-site scripting, CSRF, IDOR, SSRF, broken authentication, default credentials, weak password policy, missing security headers, TLS/SSL misconfiguration, sensitive data exposure, outdated software components, directory listing, unrestricted file upload, CORS misconfiguration, missing rate limiting, verbose error messages, and more.
Who reads them. Pentesters logging the engagement output as they test, internal AppSec teams writing up findings discovered through code review or manual testing, vulnerability management teams normalising scanner output into the same record vocabulary the rest of the workspace reads.
Cyber Essentials and Cyber Essentials Plus
Coverage. Templates aligned to the five NCSC Cyber Essentials control themes
Severity model. Control-coded rather than severity-coded, with controlRef matching the NCSC scheme
Representative templates. Firewalls (FW-01 boundary firewalls, FW-02 router and firewall configuration, FW-03 host-based firewall), Secure Configuration (SC-01 default password removal, SC-02 unnecessary account removal, SC-03 auto-run disabled), User Access Control (UAC-01 administrator separation, UAC-02 multi-factor authentication, UAC-03 password policy), Malware Protection (MP-01 anti-malware deployment, MP-02 signature updates), Patch Management (PM-01 OS patching, PM-02 application patching, PM-03 end-of-life software removal).
Who reads them. Cyber Essentials assessors, Cyber Essentials certification bodies preparing the technical evidence pack, and internal compliance teams running self-assessment readiness against the NCSC scheme.
ISO 27001 Annex A
Coverage. Templates aligned to the ISO/IEC 27001 Annex A control areas
Severity model. Control-coded rather than severity-coded, with controlRef matching the Annex A reference
Representative templates. A.5.1 Information Security Policies, A.6.1 Organisation of Information Security, A.7.2 Information Security Awareness and Training, A.8.1 Information Asset Inventory and Classification, A.9.1 Access Control Policy, A.10.1 Cryptography, A.12.4 Logging and Monitoring, A.13.1 Network Security Management, A.16.1 Incident Management, A.18.1 Compliance with Legal and Regulatory Requirements.
Who reads them. GRC teams preparing for ISO 27001 surveillance or recertification, internal audit teams running annex coverage exercises, compliance consultants running readiness sprints, and security programme managers building the statement of applicability evidence.
SOC 2 Trust Services Criteria
Coverage. Templates aligned to the AICPA SOC 2 TSC control criteria
Severity model. Criterion-coded rather than severity-coded, with controlRef matching the TSC reference
Representative templates. CC6.1 Logical and Physical Access Controls, CC6.2 User Provisioning and Deprovisioning, CC6.3 Privileged Access Management, CC7.1 System Operations Monitoring, CC7.2 System Operations Incident Response, A1.1 Availability Commitments.
Who reads them. GRC teams preparing for the next SOC 2 Type II audit window, fractional CISOs and vCISOs running readiness gap analysis for early-stage clients, internal audit teams aligning observed practice to the trust criteria evidence the auditor will request.
Incident response
Coverage. Templates for the incident classes an internal IR team needs to log under operational pressure
Severity model. Severity calibrated per incident class (critical, high, medium) with category labels
Representative templates. Confirmed data breach with regulatory notification trigger, unauthorised system access, ransomware attack with containment and recovery guidance, malware infection, phishing campaign response, business email compromise, and other classes the IR team needs to log fast without hand-typing the disposition.
Who reads them. Internal incident response leads, security operations leaders, and SOC analysts logging incidents as they unfold, with the template carrying the regulatory notification trigger and the remediation guidance the leadership readout needs.
The eleven fields every template carries
Every template is a structured object with eleven fields. The schema is consistent across cohorts so the modal logic stays simple and the applied finding lands on the record with the same shape every time.
id
A stable identifier the platform uses to reference the template internally. Each cohort uses a prefix (ce- for Cyber Essentials, iso- for ISO 27001, soc- for SOC 2, ir- for incident response) so the source cohort is visible from the identifier alone.
name
A short label the operator scans in the template picker. Distinct from the title to keep the picker readable; the title is the headline that lands on the finding record.
engagementTypes
The engagement types the template applies to. The template modal calls getTemplatesForEngagementType(engagementType) so a pentest engagement sees the pentest cohort, an ISO 27001 engagement sees the Annex A cohort, an incident response engagement sees the incident classes, and the cohorts never cross-contaminate the picker.
severity
The starting severity for the finding when the template is applied. Pentest templates carry critical, high, medium, or low. Compliance cohorts (Cyber Essentials, ISO 27001, SOC 2) carry null because the underlying engagement is control coverage rather than per-finding severity. Incident response templates carry severity to drive the leadership readout.
category
A free-text category label that drives the category filter in the template modal. Cyber Essentials uses firewalls, secure_configuration, user_access_control, malware_protection, and patch_management. ISO 27001 uses organisational, people, physical, and technological. Incident response uses data_breach, unauthorized_access, malware, phishing, and similar incident classes.
controlRef
The compliance control reference the template anchors against. Cyber Essentials templates carry NCSC scheme codes (FW-01, SC-01, UAC-01, MP-01, PM-01). ISO 27001 templates carry Annex A references (A.5.1, A.8.1, A.9.1, A.10.1, A.12.4). SOC 2 templates carry Trust Services Criteria codes (CC6.1, CC6.2, CC6.3, CC7.1, CC7.2, A1.1). Pentest templates carry null because the underlying engagement is vulnerability rather than control coverage.
title
The headline the finding carries after the template is applied. Written in the third-person observation voice the report reader expects rather than the lab voice the tester uses. Long enough to read as a finding title rather than a bare CWE category.
description
A paragraph of context explaining the vulnerability or control gap, the exploitation or non-compliance path, and the typical business impact. Written so the operator can hand it to a developer, a control owner, a CISO, a Cyber Essentials assessor, or an ISO 27001 internal auditor and it reads as standalone rather than as a fragment.
remediation
The recommended remediation or compensating control guidance, written as an action sequence the implementing team can follow rather than as a list of abstract objectives. Cross-references concrete configurations (Group Policy, web.config, NCSC guidance, vendor documentation) where the implementation path is well-defined.
affectedAsset
A placeholder for the affected asset. Defaults to null because the asset is specific to the engagement; the operator fills the asset at template-apply time. Keeping the field on the schema means the asset entry never gets forgotten during the apply step.
cvssVector
The CVSS 3.1 vector string used to seed the auto-scoring on apply. Pentest templates carry a calibrated vector that reads against the CVSS calculator immediately. Compliance and incident response cohorts carry null because severity is set elsewhere on the record. The vector is the starting point; the operator can adjust the environmental and temporal metrics on the finding record.
How the picker filters, searches, and previews
The picker is the operator interface to the library. Four mechanics keep it usable on a long list without forcing the operator to scroll the catalogue.
Engagement-type-aware picker
The modal opens with the templates already filtered to the engagement type. A pentest engagement sees the pentest cohort. A Cyber Essentials assessment sees the Cyber Essentials cohort. An incident response engagement sees the incident classes. The operator never wades through irrelevant cohorts. The mechanic is getTemplatesForEngagementType(engagementType) on the lib/finding-templates module, called once on modal open.
Category filter
When the open cohort has category labels, the modal renders a row of category pills derived from the live data. For Cyber Essentials the pills are firewalls, secure_configuration, user_access_control, malware_protection, and patch_management. For ISO 27001 the pills are organisational, people, physical, technological. For incident response the pills are data_breach, unauthorized_access, malware, phishing, and the other incident classes the cohort carries.
Full-text search across name, title, description, and controlRef
The search box matches against the template name, the title, the description, and the controlRef. Typing "A.9" surfaces every ISO 27001 access-control template. Typing "CSRF" surfaces every cross-site request forgery variant in the pentest cohort. Typing "FW-02" surfaces the firewall configuration template for Cyber Essentials. Typing "ransomware" surfaces the ransomware incident template.
CVSS preview on the picker
When a pentest template carries a CVSS vector, the picker renders the parsed score next to the template so the operator sees the starting severity before clicking apply. The vector parses through the same CVSS calculator the finding form uses, so the picker preview and the post-apply score never diverge.
The four-step apply flow
Applying a template to a finding is a four-step flow that runs in under a minute for a familiar template and under two minutes for one the operator is opening for the first time.
Open the template modal from the finding form
The finding form on an engagement carries a "Use template" button that opens the FindingTemplateModal. The modal reads the parent engagement type and filters the catalogue to the matching cohort. No global "browse all templates" dump that mixes pentest with Cyber Essentials.
Filter and search to the matching template
The operator narrows by category (if the cohort carries categories), types into the search box, and scans the result list. The picker shows the name, the title, and where applicable the severity badge and the parsed CVSS score so the operator decides without clicking through.
Apply the template to the finding form
Clicking the template populates the finding form with title, description, remediation, severity, category, controlRef, and cvssVector. The operator then fills the affected asset (always specific to the engagement) and the evidence (the screenshots, log lines, scanner output, or interview notes that prove the finding). The form retains the option to edit any of the populated fields.
Save the finding to the engagement record
The finding lands on the engagement as a structured record with CVSS auto-scoring on the vector, severity calibration, the controlRef if applicable, and the activity log entry naming the creator and the timestamp. The next person reading the finding reads the same record vocabulary the entire workspace uses.
Six failure modes the library prevents
Hand-typing the same vulnerability for the fifth engagement this quarter
Without a template library the pentester types the SQL injection description, the IDOR description, and the SSRF description on every engagement, and the writeup quality drifts across operators and across weeks. The library carries one canonical description per vulnerability class so the report reader sees consistent language across operators and engagements.
Severity drift between engagements
When each operator picks a severity from memory the same vulnerability class shows up as high on one engagement and medium on the next. The library carries a calibrated starting severity per template so the workspace severity policy travels with the finding rather than being rebuilt every time.
Inconsistent CVSS vectors across operators
CVSS vector authoring is a discipline most pentesters do not run from scratch on every engagement. The library carries a calibrated CVSS 3.1 vector per pentest template so the auto-scoring on the finding form starts from a defensible base rather than from a guess. The operator adjusts the environmental and temporal metrics for the specific engagement rather than typing the entire vector.
Compliance findings written without a control reference
When the operator types an ISO 27001 or Cyber Essentials finding from scratch the controlRef field gets left blank and the audit reader cannot map the finding to the annex or the scheme without a manual lookup. The compliance cohorts carry controlRef on every template so the finding lands on the engagement with the audit anchor pre-populated.
Cohort cross-contamination
A picker that shows every template regardless of engagement type lets a Cyber Essentials assessor accidentally drop a pentest CVSS finding into a compliance engagement, or a pentester accidentally pick a Trust Services Criteria writeup into a vulnerability assessment. The engagement-type filter on the modal removes the failure mode at the picker rather than relying on operator discipline.
Incident response writeups invented under pressure
IR engagements are logged under time pressure. Without a template the responder hand-types the data breach description, the unauthorised access description, and the ransomware description while the incident is still active, and the writeup quality reflects the pressure. The IR cohort carries pre-written descriptions and remediation sequences so the responder logs the incident class and edits the specifics rather than authoring under duress.
Five enterprise scenarios the library operates against
Internal AppSec team logging manual review findings
An AppSec engineer running a manual review of a new feature finds an IDOR on an admin endpoint and a missing CSRF token on a state-changing form. The engineer opens the finding form on the engagement, clicks Use template, types IDOR, applies the template, fills the affected endpoint and the evidence, and saves. The finding lands with the calibrated CVSS vector, the severity, the canonical description, and the remediation guidance. The next finding (CSRF) repeats the same flow. Two findings logged in under five minutes with the same writeup quality the report reader expects.
Cyber Essentials Plus assessor evidencing per-control gaps
A Cyber Essentials Plus assessor working through a sample of in-scope devices identifies a host without the host-based firewall enabled, a workstation with a remaining default credential, and an end-user account without MFA on the cloud productivity suite. Each gap maps directly to a Cyber Essentials control (FW-03, SC-01, UAC-02), and the assessor applies the matching template to log the gap with the NCSC control reference, the canonical description, and the remediation guidance. The certification body reads the per-control evidence pack against the same scheme references the IASME monitoring uses.
GRC team preparing ISO 27001 surveillance evidence
A GRC team running an internal Annex A coverage exercise ahead of surveillance applies the ISO 27001 templates to log the controls observed as in-place, partially in-place, or not in-place. Each finding carries the A. reference, the canonical description of the control objective, and the remediation guidance the gap closure plan reads against. The statement of applicability evidence reads from the same workspace the surveillance auditor will sample from rather than from a separate binder.
SOC 2 Type II readiness sprint by a vCISO
A vCISO running a readiness sprint for an early-stage client applies the SOC 2 TSC templates to log the gaps against CC6.1 access controls, CC6.2 provisioning, CC6.3 privileged access, CC7.1 monitoring, CC7.2 incident response, and A1.1 availability commitments. Each gap carries the criterion code, the canonical description, and the remediation guidance the client engineering team uses to close the gap before the Type II observation window opens.
Incident response lead logging an active ransomware incident
A SOC analyst escalates a confirmed ransomware infection on a regional file server. The IR lead opens an incident response engagement, applies the Ransomware Attack template, fills the affected hosts, the ransom note details, and the initial access vector, and saves. The finding lands with the canonical containment and recovery guidance, the regulatory notification trigger, and the structured record the leadership readout and the post-incident review will read from. The IR lead spends the time on the incident rather than on the writeup.
How audit frameworks read templated findings
Auditors reading findings authored through the template library evaluate three artefacts: the canonical vocabulary (consistent description and remediation language across engagements), the control reference where applicable (the anchor to the framework clause), and the severity and CVSS calibration where applicable (the documented rank-and-treat evidence). The library supplies all three at the point the finding is authored.
| Framework | How the templated finding reads as evidence |
|---|---|
| ISO 27001:2022 | Annex A.8.8 Management of Technical Vulnerabilities reads the populated controlRef and the canonical description as the documented identification of the technical vulnerability; A.5.31 Statutory and Regulatory Requirements reads the compliance cohort coverage as evidence of regulatory mapping; A.5.4 Management Responsibilities reads the controlRef-aligned findings as the management view of control coverage. |
| SOC 2 Trust Services Criteria | CC4.1 Monitoring of Controls reads the SOC 2 cohort findings as the per-criterion observation pack; CC9.1 Risk Mitigation reads remediation guidance on each finding as the documented mitigation plan; the controlRef on every SOC 2 template anchors the finding to the criterion the Type II auditor will sample. |
| PCI DSS v4.0 | Requirement 6.3 reads the calibrated CVSS vector and severity on every pentest template as the rank-and-treat evidence; Requirement 11.3 reads the engagement record built from the pentest cohort as the penetration testing evidence; the canonical description and remediation guidance read as the documented vulnerability handling rather than as freeform operator notes. |
| Cyber Essentials (NCSC scheme) | The NCSC-aligned controlRef on every Cyber Essentials template (FW-01, FW-02, FW-03, SC-01, SC-02, SC-03, UAC-01, UAC-02, UAC-03, MP-01, MP-02, PM-01, PM-02, PM-03) anchors every observed gap to the certification scheme so the certification body reads the per-control evidence pack against the same scheme references the IASME assessor uses. |
| NIST SP 800-53 Rev. 5 | RA-5 Vulnerability Monitoring reads the pentest cohort findings as the vulnerability identification record; CA-2 Control Assessments reads the compliance cohort findings as the assessment output; SI-2 Flaw Remediation reads the remediation guidance on every finding as the documented mitigation. The controlRef on the compliance cohorts and the canonical descriptions on the pentest cohort together form the documented finding identification chain. |
How the template library pairs with the rest of the platform
The record store the templates apply to. Findings management carries the captured finding with CVSS 3.1 scoring, severity, category, controlRef, the affected asset, and the evidence; the template library seeds the textual fields and the calibrated starting values.
The downstream consumer of the consistent finding language the template library produces. Executive summaries, technical writeups, and remediation roadmaps draft cleaner when every finding on the engagement uses the same canonical vocabulary rather than five operators authoring the same vulnerability five different ways.
The intake path for Nessus, Burp Suite, and CSV. Templates are the manual companion to import: scanner findings land through bulk import, manual findings land through the template picker, and both share the same finding record vocabulary so the workspace operates one queue rather than two.
The disposition layer that decorates findings authored through templates the same way it decorates findings imported from scanners. False positive, accepted risk, and severity override decisions travel with the finding regardless of whether it started as a template or as a scanner result.
The framework layer that reads the controlRef on every finding to map control coverage across Cyber Essentials, ISO 27001, SOC 2, NIST 800-53, PCI DSS, and the other framework templates. The library populates the controlRef at template-apply time so the compliance view never has to reconstruct the mapping after the fact.
The engagement-type signal that drives the picker filter. The engagement carries the type (pentest, vulnerability assessment, Cyber Essentials, ISO 27001, SOC 2, incident response, other); the picker reads the type and surfaces the matching cohort.
An eight-item operating checklist
The library is only as useful as the discipline the operator runs against it. These eight habits keep applied templates honest across engagements and across operators.
- Confirm the engagement type on the engagement record matches the cohort the operator wants the picker to surface (a Cyber Essentials assessment logged as a pentest engagement will surface the pentest cohort rather than the NCSC scheme cohort)
- Use the template as a starting point and edit the description to reflect the specific evidence on the engagement; templates are calibrated language, not a substitute for engagement context
- Fill the affected asset on every applied template; the field is intentionally left null in the template so the operator never forgets the asset binding
- Adjust the CVSS environmental and temporal metrics on the finding form when the engagement context changes the severity (the template vector is the base, the engagement context is the calibration)
- Preserve the controlRef on compliance findings; the audit view reads the controlRef as the anchor to the annex or the scheme
- When a template does not exist for the observed vulnerability or control gap, author a fresh finding manually rather than forcing an unrelated template to fit; the library is a high-coverage starter set, not a closed taxonomy
- For repeat vulnerability classes across engagements, prefer the canonical template over a copy-paste of a previous finding; the canonical vocabulary keeps the report reader oriented across engagements and across operators
- For incident response engagements, apply the template fast and edit the specifics later; the IR record value is in the timeline, not in the writeup quality at the moment of logging
Scope and honest limits
The library is a high-coverage starter set, not a closed taxonomy. The list below names what the feature does and does not do, so operators choose the right place for the work that sits outside its scope.
- The library is a starter set for the most common vulnerability classes and the most common compliance control objectives, not a complete taxonomy. Operators authoring findings for vulnerability classes that are not in the library use the freeform finding form to log the finding manually.
- Templates are read-only on the platform; SecPortal does not ship a workspace-side template editor. Workspaces that need to customise descriptions or remediation guidance edit the populated finding form after applying the template, or contribute a refinement back to the canonical library.
- The CVSS vectors on the pentest cohort are starting calibrations, not final severities. The environmental and temporal metrics depend on the engagement context and the deployment specifics; operators adjust both on the finding record after applying the template.
- The compliance cohorts (Cyber Essentials, ISO 27001, SOC 2) cover representative controls and criteria, not every clause in every standard. The library helps operators log the observations fast; the full Statement of Applicability or Trust Services Criteria coverage view lives on the engagement record alongside the findings.
- The library does not synchronise to Jira, ServiceNow, Linear, Azure DevOps, or any external ticketing system. Findings authored through templates live on the workspace operating record; integrations with external systems are operator-driven exports rather than packaged connectors.
- The IR cohort covers common incident classes the responder needs to log under pressure; it is not a substitute for the runbook the IR programme operates against. The template carries the canonical writeup and the remediation guidance; the engagement-level runbook carries the operational sequence.
Where to read next
For the structured record the templates apply to (CVSS 3.1 scoring, severity, category, controlRef, asset binding, evidence, status), see findings management.
For the downstream consumer of the consistent finding language the library produces (executive summaries, technical writeups, remediation roadmaps drafted in seconds rather than days), see AI-powered report generation.
For the framework layer that reads the controlRef on every template across Cyber Essentials, ISO 27001, SOC 2, PCI DSS, NIST 800-53, and the other framework templates, see compliance tracking.
For the intake path the library complements when the findings come from a third-party scanner rather than from a manual review (Nessus, Burp Suite, CSV), see bulk finding import.
For the workflow that turns templated findings into a delivered engagement (scope, ROE, evidence, report, retest, closure), see the penetration testing workflow.
For the workflow the AppSec team uses to turn library-language findings into developer-actionable tasks (translation, evidence, owner assignment), see security finding translation into developer language.
For the conceptual layer on why workspaces benefit from a canonical finding vocabulary across operators and engagements, see the vulnerability programme data model research.
Underlying platform mechanics worth knowing
Library as code, not as content
Every template lives in the application bundle as a typed FindingTemplate record. Builds carry the library; there is no external content fetch on template open. The picker is fast because the catalogue is local.
Engagement-type cohort partition
The cohort partition is enforced by the engagementTypes field on every template. The picker calls getTemplatesForEngagementType(engagementType) and only the matching cohort appears. The operator cannot accidentally cross-contaminate a Cyber Essentials assessment with a pentest finding.
CVSS calculator shared with the finding form
The CVSS preview on the picker parses the template vector through the same calculator the finding form uses on save. The picker preview and the saved score never diverge because both read the same lib/cvss parser.
Activity log captures template apply events
Saving a templated finding lands on the engagement as a finding create event in the activity log with the actor, the timestamp, and the engagement reference. The audit reader sees the same trail for templated findings as for findings authored from scratch.
Stop typing the same finding for the fifth time this quarter
Open the template modal, pick the matching vulnerability or control, and the finding lands on the engagement with title, description, remediation, severity, and the CVSS vector. The operator edits the evidence and the asset rather than the writeup.
No credit card required. Free plan available forever.