CTEM Templates Pack: Six Records That Keep a Programme Honest

• Why templates beat documentation
• The scope record and its fields
• How to publish a prioritization rule set
• What belongs in a validation record
• A remediation work item engineers accept
• An exception form that expires by design
• The quarterly executive one pager

Templates carry the process; documents describe it

Most programmes have a policy document nobody opens and a set of habits that vary by analyst. Templates fix that by moving the process into the artefacts people fill in during normal work. When a field is mandatory in the form, it gets answered. When it lives in a policy PDF, it does not. Keep every template short enough that filling it in is faster than arguing about it.

Template one: the scope record

One record per business service in scope for the cycle. It exists so nobody can later claim they did not know a system was included, and so testing constraints are agreed before a validation engineer needs them.

• Business service, criticality tier and executive owner
• Assets, data stores, cloud accounts and identities that support the service
• Explicit exclusions for this cycle and the reason for each
• Testing constraints: change windows, prohibited techniques and required approvals
• Review date and sign off

Template two: the prioritization rule set

This is a one page published statement of how ranking is decided, so priority is a calculation rather than an opinion. State the inputs, the order in which they apply, and the override conditions. Publish it to engineering teams, because a prioritization model that only security can see will be challenged in every meeting.

Template three: the validation record

The validation record is the evidence artefact. Written properly, it lets a colleague reproduce the test and an auditor accept the conclusion a year later without speaking to the person who ran it.

1. 1Target asset, business service and the hypothesis being tested.
2. 2Technique emulated and its public reference identifier.
3. 3Execution detail: timestamp, source, operator, approval reference and scope constraints.
4. 4Outcome: exploitable or not, with the observable evidence.
5. 5Control response: what blocked it, what alerted, and what neither did.
6. 6Retest: date, result and the evidence that the fix held.

Template four: the remediation work item

Write it for the engineer who will do the work, not for the security team. The test of a good work item is that someone unfamiliar with the finding can complete it without asking a question. Include the specific action, the affected instances, the evidence, the deadline with its justification, and what verification will be performed.

Template five: the exception form

The exception form is the most important template because it is the one that most often goes wrong. Make expiry mandatory and enforced by the workflow, require validation evidence for the compensating control, and require a named individual rather than a team as the accepting owner.

• Exposure reference and the business reason the fix is not possible now
• Named accepting owner and their management level, matched to the risk tier
• Compensating control described, with validation evidence attached
• Expiry date enforced by the ticket workflow, plus a review trigger such as confirmed exploitation
• Renewal requires fresh validation evidence, not a copy of the original

Template six: the quarterly executive one pager

One page, five metrics with trends, one sentence on what changed, the decisions you need, and the risks being formally accepted. Anything longer becomes a document that gets skimmed, and the decisions you needed get deferred.

• Create the six templates as forms in the systems your teams already use.
• Make expiry and named ownership mandatory fields on the exception form.
• Publish the prioritization rule set to engineering, not just to security.
• Attach validation evidence to work items so closure can be verified.
• Keep the executive report to one page and review the templates quarterly.

• Writing a long policy document instead of short mandatory forms.
• Allowing exceptions without an expiry date or a named individual owner.
• Recording validation conclusions without reproducible detail.
• Writing work items in security language engineers cannot act on.
• Letting the executive report grow past one page.