A security problem record is only useful if every team fills it in the same way, and most ITSM problem forms were designed for outages, not control gaps. This template gives you a ready-to-copy record for security problems: the header, the fields for cause, failed control, owner, workaround, permanent fix and verification, the allowed values for each, and a fully worked example. It is the companion form to the Problem Management for Security guide, which explains the method (triggers, analysis techniques, prioritisation and metrics); this page does not repeat it. Use it alongside the Post-Incident Review and Root Cause Analysis Template: the review finds causes, and this record carries each cause until the fix is proven. It is written for problem managers, SOC leads, ITSM tool owners and the control owners who will be named on the record.
How to use this template
- Copy the sections into your ITSM problem module: each numbered section below becomes a field group. Fields marked (required) block a status change until they are filled.
- Replace the placeholders: text in square brackets such as [Organisation], [Problem manager] and [Risk scale] is for you to set once, organisation-wide.
- One record per cause, not per incident: if two incidents share a cause, link both to one record. If one incident has two independent causes, open two records. The Incident Management vs Problem Management guide explains the split.
- Restrict access: a security problem record describes an unfixed weakness. Limit visibility to the security team, the named control owner and approvers, and never paste credentials, exploit detail or personal data into it.
- Keep it alive: the record is reviewed monthly until closure, so write for a reader who was not in the incident.
| Field | What to enter | Allowed values or format |
|---|
| Problem ID (required) | Unique reference generated by the tool | [PRB-SEC-YYYY-NNN] |
| Title (required) | Short name of the cause, not the symptom | Under 80 characters, no system hostnames or secrets |
| Status (required) | Current life cycle stage | New, Under analysis, Known error, Fix in progress, Verifying, Closed, Closed as risk accepted (see section 9) |
| Priority (required) | Result of section 6 risk rating | P1 to P4 per [Risk scale] |
| Category | Control domain where the cause sits | Identity and access, Secrets, Configuration, Detection, Process, Supplier, People, Software flaw |
| Opened by and date | Who raised it and when | Name, ISO date |
| Trigger | Why the record was opened | High-severity incident, Recurrence threshold, Detection failure, Near miss, Audit or test finding, Repeat exception |
| Problem manager (required) | Person who runs the record to closure | Named individual, not a team mailbox |
| Confidentiality | Handling marking for the record | [Classification scheme], default restricted |
2. Problem statement and scope
Write one sentence that names the cause and the condition that allows it, then one sentence on scope.
- Problem statement (required): "[Asset class or process] allows [condition], which leads to [type of incident]." Test it: if the statement would still be true after the fix, it describes a symptom, not the cause.
- Scope: the systems, business units, identity types and environments affected, and those confirmed not affected.
- First and latest occurrence: dates of the earliest and most recent linked event.
- Out of scope: related issues deliberately left to another record, with their IDs.
3. Linked incidents, near misses and evidence
| Ref | Type | Date | Severity | How it was detected | Link to the cause |
|---|
| [INC-...] | Incident, near miss, alert cluster, test finding | [Date] | [Severity] | Monitoring, user report, third party, chance | One line on how this event shows the cause |
- Evidence locations: where the timelines, log extracts and review reports are held, by reference only. Evidence itself stays in the incident case under its chain of custody.
- Review references: the post-incident review IDs that produced or confirmed this cause.
- ATT&CK technique tags: optional, but tagging linked incidents consistently is what makes recurrence countable.
4. Root cause and control gap
| Field | What to enter |
|---|
| Root cause (required before Known error) | The systemic cause found by analysis, backed by evidence. Never a person's name or "user error". |
| Analysis method | Timeline, five whys, fishbone, control path analysis, or a combination |
| Failed or missing control (required) | The control, standard, runbook step or design decision that should have prevented or detected the event. State whether it was absent, bypassed, misconfigured or failed. |
| Control reference | Internal control ID plus any framework reference you use, for example ISO/IEC 27001:2022 Annex A control number, NIST SP 800-53 control or CSF 2.0 subcategory |
| Contributing factors | Technical, process, organisational and supplier factors, and any change in the threat |
| Detection gap | Why monitoring did or did not see it, and how long the condition existed before detection |
| Alternative outcomes | What would have happened with a more privileged target or a more capable attacker |
| Confidence | Confirmed, Probable, Hypothesis. A hypothesis cannot move the record to Known error. |
5. Ownership and accountability
- Control owner (required before Known error): the person accountable for the control that failed, usually outside the SOC: identity, cloud platform, application, HR or a supplier manager.
- Fix owner: the person or team delivering the change, if different from the control owner.
- Risk owner: the business owner who would accept the residual risk if the fix is deferred.
- Escalation route: who the problem manager escalates to if a due date is missed, for example [Security steering group].
- Acknowledgement: date each named owner accepted the assignment. An unacknowledged assignment after [10 working days] escalates automatically.
6. Risk rating and priority
| Factor | Question to answer | Scale |
|---|
| Recurrence likelihood | How often has it happened, and is it still exploitable today? | [1 to 5] |
| Plausible worst impact | What is the worst credible outcome, not the worst so far? | [1 to 5] |
| Control leverage | Does fixing this close other open problems? | Yes or no, with IDs |
| Workaround cost | Hours per month spent on the workaround | Number |
| Regulatory or contractual exposure | Would recurrence trigger a notification duty or breach a contract? | Yes or no, with the obligation named |
| Resulting priority | Mapped from likelihood and impact on [Risk scale] | P1 to P4, with target fix date |
If a known error stays open beyond [90 days] or past its target date, add it to the Risk Register Template entry for the affected service so the acceptance is explicit and owned.
7. Workaround
| Field | What to enter |
|---|
| Workaround description | The compensating action that reduces impact until the fix lands |
| Performed by | Role or automation that executes it, and where the runbook step lives |
| Start date and expiry (required) | The workaround lapses on this date unless renewed by the risk owner |
| Monitoring rule | How you know the workaround is being applied every time |
| Residual risk | What the workaround does not cover |
| Renewal history | Each renewal with approver and reason. More than [two] renewals forces escalation. |
Treat a renewed workaround the way you would a policy exception: see the Security Exceptions and Risk Acceptance Guide.
8. Permanent fix
- Fix description (required before Fix in progress): the change that removes the cause, written as an outcome ("all new keys carry a maximum lifetime of [N] days") not an activity ("review keys").
- Change references: each change record, with the problem ID quoted on the change. See the Change Management Security guide.
- Stages: for staged rollouts, list each stage, its scope and its planned and actual dates. The record stays open until the last stage is verified.
- Rollback plan: how the change is reversed if it breaks service, and which workaround resumes if it is.
- Related control updates: standards, runbooks, detection rules and training material changed as a result.
- Target date and actual date: both recorded; a moved target date needs the risk owner's approval.
9. Verification and closure
| Field | What to enter |
|---|
| Verification criteria (required before Verifying) | Defined before the fix is deployed: the evidence that proves the cause is gone |
| Verification period | How long the evidence must hold, for example [60 days] with no linked recurrence |
| Verification evidence | Test results, configuration exports, detection hits, sampled records, with dates |
| Verified by | Someone other than the fix owner, such as second line or internal audit for P1 problems |
| Closure code (required) | Fixed and verified; Closed as risk accepted (risk owner signature and review date); Duplicate (with the surviving ID); No systemic cause (with analysis reference) |
| Reopen rule | Any new incident linked to this cause within [12 months] reopens this record rather than creating a new one |
Status rules
| Move to | Only when |
|---|
| Under analysis | Problem manager assigned and at least one linked event recorded |
| Known error | Root cause confirmed or probable, failed control named, control owner acknowledged |
| Fix in progress | Fix described, change raised, workaround with expiry in place or explicitly not needed |
| Verifying | Last fix stage deployed and verification criteria recorded |
| Closed | Verification period passed with evidence, verified by an independent reviewer |
10. Review and approval
- Monthly problem review: [Problem manager] presents open records, workaround expiries and verification evidence to control owners.
- Steering report: top problems by priority, age and repeat incident count go to [Security steering group] each month.
- Template ownership: [Head of security operations] owns this template and reviews it every [12 months] or after a process failure.
- Version: [Template version], approved by [Approver] on [Date].
11. Worked example
The example below is illustrative and uses a fictional organisation. It shows how the fields read when filled in properly.
| Field | Example entry |
|---|
| Problem ID and title | PRB-SEC-2026-014: CI pipelines print cloud credentials to build logs |
| Status and priority | Verifying, P2 |
| Trigger | Recurrence threshold: three related incidents in 90 days |
| Problem statement | Shared build templates echo environment variables in debug mode, which exposes deployment credentials to anyone with log access. |
| Scope | All pipelines built from the shared template (about 140); pipelines on the newer template are confirmed unaffected |
| Linked events | Three incidents: a key found by the secrets scanner in an archived log, a key reported by a contractor, a key used from an unknown network (found by cloud audit alerting); one near miss from a test finding |
| Root cause | Debug flag defaulted to on in the shared template; the log platform masks only secrets registered with the vault plug-in, and these were injected as plain variables |
| Failed controls | Secret masking in CI (misconfigured); long-lived deployment keys instead of short-lived workload credentials (absent); log access restricted to pipeline owners (bypassed by a broad reader role) |
| Contributing factors | Template owned by a team that was reorganised; no secrets scanning on build logs until the second incident |
| Owners | Control owner: platform engineering lead. Fix owner: CI platform team. Risk owner: head of engineering |
| Workaround | Daily scanner run over build logs with automatic key revocation on a hit; expiry 31 days after start, renewed once |
| Permanent fix | Stage 1: debug off by default and masking for all injected variables. Stage 2: replace stored keys with federated short-lived credentials. Stage 3: narrow the log reader role |
| Verification | 60 days with zero scanner hits on build logs, no stored long-lived deployment keys in the CI secret store, quarterly access review of the log reader role |
| Closure | Pending: verification period ends in [date]; independent check by second line |
Note what the example avoids: no key values, no blame on the contractor who reported it, and a fix written as measurable outcomes. For the identity side of fixes like stage 2, see the Service Account Security Guide.
Implementation guidance
- Configure the tool first: build the field groups above in your ITSM problem module with a security category, the status rules as workflow conditions and restricted visibility.
- Pilot on real data: backfill three to five records from the last year's incidents and check that each field can be completed from evidence you hold. Drop or merge fields nobody can fill.
- Agree the scales: link the section 6 rating to the enterprise risk scale rather than inventing a new one, and set the placeholder durations (workaround expiry, verification period, reopen window).
- Train the owners: control owners outside security need ten minutes on what acknowledgement means and what verification evidence looks like.
- Link to remediation tracking: if you run a plan of action and milestones, reference the problem ID there instead of duplicating it. See the Plan of Action and Milestones (POA&M) Guide.
- Report from the fields: once records are consistent, the monthly steering report can be generated from status, priority, age, workaround expiry and linked incident count rather than written by hand. A record that cannot be reported on usually has free text where a structured field belongs.
- Audit the records: each quarter, sample five closed records and check that verification evidence exists, was independent and covers the full period. Reopen any record closed on deployment date alone.
- Roll back if needed: if the full template slows incident closure during the pilot, make only sections 1, 2, 4, 5 and 9 required and add the rest after one quarter.
Common mistakes when filling in the record
- Symptom as title: "Key leaked again" instead of the condition that leaks keys.
- Team as owner: a distribution list cannot be escalated; name a person.
- No expiry on the workaround: it silently becomes the control.
- Verification defined after the fix: criteria chosen to match whatever the fix achieved.
- Sensitive detail in free text: credentials, hostnames of unpatched systems or personal data copied from the incident.
Framework alignment
| Template section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|
| 4. Root cause and control gap | RS.AN-03 | IR-4 Incident Handling |
| 6 to 8. Risk, workaround, fix | ID.IM-03 | CA-5 Plan of Action and Milestones; PM-4 Plan of Action and Milestones Process |
| 8. Permanent fix for software flaws | ID.IM-01 | SI-2 Flaw Remediation |
| 9 and 10. Verification and review | ID.IM-04 | IR-4 Incident Handling |
Standards and references
Related NHI Mgmt Group resources: Problem Management for Security · Post-Incident Review and Root Cause Analysis Template · Incident Management vs Problem Management · Major Incident Management · ITIL 4 Information Security Management Guide
NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 14 November 2026. Spotted an error? Use our
contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security.
nhimg.org