Building a custom control framework from your own documents

Plenty of real obligations never arrive as a tidy published standard. They come as a customer's security schedule, a group policy from a parent company, a regulator's PDF, or a contract annex. You still have to assess against them, evidence them and report on them - which means turning prose into a structured control set.

When you need a custom framework

• A major customer imposes their own security standard as a contractual condition.
• A parent company mandates a group-wide control set.
• A regulator publishes requirements your tooling does not carry.
• You maintain an internal standard stricter than any external framework.
• You operate in a niche sector whose framework is not in any vendor catalogue.

The alternative - tracking it in a side spreadsheet - is how organisations end up with two disconnected compliance programmes and contradictory answers to the same question.

From document to control set

1. Extract the requirements. Work through the source and pull out every statement that imposes an obligation. Watch for requirements buried in prose rather than numbered lists - that is where completeness is usually lost.
2. Give each one an identifier, ideally preserving the source numbering so an assessor can trace it back.
3. Split compound requirements. "Access shall be reviewed quarterly and privileged access monthly" is two controls with different evidence and cadence.
4. Record the source reference - document, version, section - for every control. Without it you cannot defend your interpretation later.
5. Group into domains so the set is navigable and reportable.
6. Note the assessment basis - implementation status, maturity, or applicability - because different sources expect different scoring.

Completeness is the hard part

The common failure is silent omission - a requirement in a paragraph nobody converted into a control. Two habits prevent it:

• Count and reconcile. If the source has 84 numbered requirements, your framework should account for all 84 - including any you deliberately marked out of scope, with a reason.
• Check for sequence gaps. Missing identifiers in a numbered sequence are the fastest signal that extraction dropped something.

Record exclusions explicitly rather than deleting them. "Not applicable because we do not operate industrial control systems" is a defensible position; a requirement that simply vanished is not.

Map it, do not run it separately

Once structured, map the custom framework onto your existing control library. Most requirements will already be satisfied by something you operate - the same access review, the same encryption standard. What remains after mapping is your genuine delta, and it is usually far smaller than the document's length suggests.

This is the whole point: a 200-requirement customer standard often resolves to a handful of new controls plus a large amount of evidence you already hold.

Keeping it current

• Record the source version. When the customer issues v3, you need to diff against v2.
• Assign an owner for the framework itself, not just its controls.
• Re-run the mapping when either the source or your control library changes.
• Keep superseded versions - assessments were made against them.

Key takeaways

• Real obligations often arrive as documents, not published standards.
• Split compound requirements and keep source references for traceability.
• Reconcile counts and sequence gaps - silent omission is the main risk.
• Map to your existing library; the true delta is usually small.