Control ownership and the control catalogue

Scope: every control the organisation operates · Who: the officer who owns the control set · Prerequisites: a Statement of Applicability, a policy set, an audit calendar · First result: six weeks

1. Why this exists (the failure mode it prevents)#

The parts are usually present. A Statement of Applicability exists, the policy set is written, the audit calendar is booked, and control work happens in a ticket queue. Missing is one list that answers three questions about any single control. Who owns it, what record it leaves, and when it was last tested.

Without that list, a control exists in three places at once. The Statement of Applicability holds one description, written to answer clause 6.1.3, Information security risk treatment ¹. The policy set holds a second, written for a reader. The configuration tool holds a third. None names an owner, and the three drift apart between audits.

The second failure is quieter and more common. The catalogue is shaped like a framework: one row per reference control, no row per thing that runs. Annex A is titled Information security controls reference ². It is a comparison set used to check that nothing necessary was omitted, not an inventory of operations. A catalogue built from it describes the standard rather than the organisation.

Both failures surface the same way. Questions about the Statement of Applicability get answered from memory. Successive audits find the same control unowned. A test result arrives that nobody can attach to a control, and is filed.

A catalogue is where the three disciplines meet, and the meeting is one loop rather than three silos. Governance decides who is accountable for each control and who may change it. Risk supplies the reason each control exists and the priority it carries. A treatment plan states the rationale for the chosen option and names those accountable for approving and implementing it ³. Compliance then demonstrates that what was decided actually ran, using the records and test results the catalogue points at. Remove any one of the three and the other two stop working.

2. Definitions (only the ones that cause disputes)#

Eight terms decide whether a catalogue holds. Requirement text is paraphrased; only titles quoted.

Term	Working definition	Source
Control	A measure that maintains or modifies risk. The definition is deliberately wide: a process, a policy, a device or a practice all qualify, and a control may not have the effect assumed of it.	ISO/IEC 27002:2022 clause 3.1.8 4
Control objective	What the control is for, in one sentence, taken from the risk decision or the obligation. Each reference control carries a Purpose line for exactly this job.	ISO/IEC 27002:2022 clause 4.3 5
Control owner	The role accountable that the control operates as designed. Tasks may be delegated, but the holder stays accountable and has to determine that delegated tasks were performed correctly.	Annex A / ISO/IEC 27002:2022 control 5.2 Information security roles and responsibilities 6
Evidence producer	The role whose routine work creates the record. Documented operating procedures are expected to specify the responsible individuals and the handling of the information involved.	Annex A / ISO/IEC 27002:2022 control 5.37 Documented operating procedures 7
Control instance	One place a control runs: a platform, a region, a subsidiary. One control, several instances, one owner per instance where the operator differs.	Method, against clause 8.1 Operational planning and control 8
Attributes	Five attributes shipped with the reference set, each with printed values, used to filter, sort or present controls in views for different audiences.	ISO/IEC 27002:2022 clause 4.2 9
Test	A periodic check that the control did what it was designed to do, against a sample and a stated method. Clause 9.1 is Monitoring, measurement, analysis and evaluation.	ISO/IEC 27001:2022 clause 9.1 10
Monitoring	Continuous or periodic watching of networks, systems and applications for anomalous behaviour, with records kept for defined retention periods. A monitoring feed is not a test result.	Annex A / ISO/IEC 27002:2022 control 8.16 Monitoring activities 11

The Statement of Applicability sits underneath all eight. It comes out of the treatment step at clause 6.1.3, and the catalogue is what makes it answerable ¹.

3. The method — numbered steps, each with input, activity, output and owner#

Nine steps. The first three fix the unit, the contents and the ownership. The next three attach attributes, evidence and tests. The last three handle gaps, change and measures.

3.1 Decide the unit before writing a single row#

A control is a thing that runs. It has an operator, a cadence and an output. A framework line is not a control; it is a requirement one or more controls satisfy. Getting this wrong produces a catalogue nobody can test.

The reference set is organised as organisational, people, physical and technological controls ¹². That is a filing scheme for a document, not the shape of an operation, where one patch cycle satisfies several reference lines.

Three tests decide whether a candidate row is a control. Can a role be named who answers for it. Does running it produce a record. Could a competent outsider observe it happening. Two negatives mean the row belongs in a different column.

• Input: the Statement of Applicability; the policy set; the ticket queue; configuration baselines.
• Activity: apply the three tests to every candidate; split anything that bundles several operations; merge duplicates describing one operation in different words.
• Output: control unit rule, one paragraph, plus the first list of candidate controls.
• Owner: the officer who owns the control set; each function head confirms their own operations.

3.2 Build from what runs, then map upward#

Start from the operations, not from the framework. Walk each function and write down what it does on a cadence: the access review, the backup restore test, the vulnerability cycle, the supplier assessment. That list is the catalogue's first draft.

Only then map upward. Each control gets the reference control numbers it serves, the obligation identifiers it answers, and a Framework Category from CSF 2.0 as a cross-reference ¹³. One control commonly carries several. A patch cycle answers reference control 8.8, whose control statement is that information about technical vulnerabilities is obtained, exposure evaluated and appropriate measures taken ¹⁴. The same cycle answers the NIS2 measure on security in acquisition, development and maintenance, including vulnerability handling and disclosure ¹⁵.

The obligation column is filled from an obligations register, not invented here. From regulation to controls is the method that produces it; this playbook consumes its output.

• Input: the candidate list from 3.1; the obligations register; the Statement of Applicability.
• Activity: write one row per operation; attach reference control numbers, obligation identifiers and CSF Subcategories; mark reference controls with no operation as gaps.
• Output: control catalogue, first draft, plus a gap list.
• Owner: the officer who owns the control set; function heads confirm the mapping for their own rows.

3.3 One owner, one evidence producer, one approver#

Three roles per control, never fewer, never a person. Reference control 5.2 asks that information security roles and responsibilities are defined and allocated to the organisation's needs. Each area of responsibility is defined, documented and communicated, and authorisation levels documented ⁶. A blank owner column is the finding, already written.

The three do different work. The owner answers for the control operating as designed. The evidence producer creates the record, often as a by-product of the operation. The approver's decision binds when the control changes or is retired. Management is expected to require all personnel to apply information security in accordance with the policy set and procedures ¹⁶.

Where one role holds two of the three, record the overlap. Reference control 5.3 names designing, auditing and assuring information security controls among activities that can require separation. Where segregation is impractical, it points to monitoring, audit trails and management supervision ¹⁷. Which overlaps are tolerated is a decision-rights question, answered in the security operating model.

• Input: the first-draft catalogue; the role model; the decision-rights table.
• Activity: assign owner, evidence producer and approver to every row; list the rows where one role holds two of the three; record the compensating control for each.
• Output: owner matrix, one row per control, three role columns and an overlap note.
• Owner: the officer who owns the control set; top management approves the overlaps.

3.4 Carry the attributes that earn their keep#

Each control in the reference set carries five attributes with printed values, usable to filter, sort or present controls in different views ⁹. The values are worth knowing before deciding which to copy into the catalogue.

Attribute	Values as printed	Worth carrying
Control type	Preventive, Detective, Corrective	Yes — it sets what a test can prove
Information security properties	Confidentiality, Integrity, Availability	Yes — it makes coverage gaps visible
Cybersecurity concepts	Identify, Protect, Detect, Respond, Recover	Only if CSF is already the cross-reference
Operational capabilities	Fifteen values, from Governance to Information_security_assurance	Rarely — it duplicates the function column
Security domains	Governance_and_Ecosystem, Protection, Defence, Resilience	Yes — it groups reporting for an audience

Organisations may disregard one or more of these attributes, and may create attributes of their own with their own values ⁹. Three columns are usually enough: type, property and domain. Every further attribute is a column somebody has to keep true.

• Input: the catalogue with owners.
• Activity: pick the attributes to carry and say why; fill them per control; add at most one organisation-specific attribute, with its value list written down.
• Output: attribute scheme, half a page, plus the filled columns.
• Owner: the officer who owns the control set.

3.5 Name the evidence before anyone asks for it#

Evidence is a record, not a system. Four fields make it inspectable: the record, its producer, how often it appears, and how long it is kept. Clause 7.5 covers documented information, with 7.5.3 titled Control of documented information ¹⁸.

A good evidence row lets a stranger fetch the record without asking where it lives. "Access review completed" is not a record. "Quarterly access review export, signed by the system owner, in the governance space" is one. Where the record does not exist, write the row and open an action; a blank evidence column is indistinguishable from a control that never ran.

Retention is where regulated organisations differ, and the catalogue is where the difference is recorded rather than remembered. Product organisations carry duties from Regulation (EU) 2024/2847. Its Annex I Part I sets essential cybersecurity requirements for the properties of products with digital elements ¹⁹. Financial entities design, procure and implement ICT security policies and tools that keep resilience, continuity and availability for critical or important functions ²⁰.

• Input: the catalogue with owners and attributes; the retention rules that apply.
• Activity: name the record, producer, frequency and retention per control; check each record exists; open an action where it does not.
• Output: evidence schedule, one row per record, cross-referenced to control identifiers.
• Owner: the evidence producer owns the record; the officer owns the schedule.

3.6 Write the test plan as method, not as a promise#

A test proves one thing: that the control did what it was designed to do, over a stated period, on a stated sample. Clause 9.1 is Monitoring, measurement, analysis and evaluation ¹⁰. Reference control 5.36 expects compliance with the policy set, rules and standards to be reviewed regularly, with results and corrective actions recorded and kept ²¹.

Four fields make a test repeatable: what it proves, the method, the sample, and the tester's role. Sample size is a method choice rather than a standards requirement, so write the rule, scale it to population and risk, and apply it consistently.

Frequency follows risk rather than the calendar's convenience, and the register says which control carries which risk. The appetite and criteria behind that judgement belong to risk appetite and criteria that decisions can use.

Independence is the part most often missed. Reference control 5.35 expects the approach to managing information security to be reviewed independently at planned intervals or on significant change. The reviewer is independent of the area under review and outside its line of authority ²². Clause 9.2 requires a planned internal audit programme, with auditors selected so objectivity and impartiality are preserved ²³. Clause 9.2.2 is titled Internal audit programme ²⁴. The catalogue names the tester's role; running the external audit builds the programme around it.

• Input: the catalogue with evidence rows; the risk register; the assurance plan.
• Activity: write what each test proves, its method, sample and frequency; assign a tester role that is not the owner; put the dates in the assurance plan.
• Output: test plan, one row per control, plus the sampling rule.
• Owner: the assurance function owns the plan; control owners supply the method.

3.7 Record gaps and exceptions where the auditor will look#

Two things get confused here. A gap is a requirement with no control behind it. An exception is a control that exists but is not met in a stated case, for a stated period, with an approver.

Gaps live in the catalogue as rows with an objective, no operation, and an owner for closing them. Exceptions live beside it with an expiry date. An exception with no expiry is an undocumented change to the control set. Reference control 5.36 expects the causes of any non-compliance to be identified, and corrective actions evaluated, implemented and reviewed for effectiveness ²¹.

Both feed the risk side. Where a gap or exception leaves risk above appetite, the decision is an acceptance, recorded as one by a role entitled to take it — see risk acceptance and residual risk. The loop closes the other way: compliance finds the gap, risk prices it, governance decides who carries it.

• Input: the gap list from 3.2; failed tests from 3.6; the risk register.
• Activity: record each gap with an owner and a target date; record each exception with an approver and an expiry; open an acceptance where residual risk exceeds appetite.
• Output: gap and exception log, cross-referenced to the register.
• Owner: the officer who owns the control set; risk owners approve acceptances.

3.8 Keep it alive on triggers, not on enthusiasm#

A catalogue with no change triggers is wrong within a year. Six triggers cover most movement, each naming the artefact it reopens.

• A new or changed obligation. The obligations register moves first, then the mapping column here.
• A risk decision. A new treatment adds a control; a closed risk may retire one.
• A failed test. The row reopens with a corrective action. Clause 10.2 is Nonconformity and corrective action ²⁵.
• A change of operator. New platform, new supplier, new team: the owner and evidence columns are re-confirmed.
• A supplier change. Reference control 5.19 expects processes and procedures to be defined and implemented for the information security risks of using suppliers' products or services ²⁶. See the third-party risk lifecycle.
• The annual refresh. The Statement of Applicability and the catalogue are reconciled row by row, and the differences are the year's real change.

Retirement deserves its own rule. A control is retired by a dated decision, with the risk it carried reassigned or accepted. A control that quietly stops running has not been retired; it has failed.

• Input: the catalogue; the obligations register; the risk register; test results.
• Activity: review the triggers on a stated cadence; reopen the affected rows; record the review even when nothing moved.
• Output: change record, with the trigger, the rows touched and the date.
• Owner: the officer who owns the control set.

3.9 Measure the catalogue, not the effort#

Four measures tell whether the catalogue is real, each a fraction with a defined denominator, reported on the same cycle.

Measure	Definition	What a bad number means
Owned	Controls with all three roles filled, over all controls	Nobody answers for the rest
Tested in period	Controls tested within their stated frequency, over all controls due	The plan is aspirational
Failed tests open	Failed tests without a closed corrective action, over failed tests	Findings are recorded, not fixed
Evidence overdue	Evidence records past their due date, over records due	Audit will hunt, and will find gaps

Improvements identified from evaluations, and from security tests and exercises, are a Category of their own in CSF 2.0 ²⁷. Report the four into management review, where they become decisions rather than a status page. Board and management reporting for security covers the upward half.

• Input: the catalogue, evidence schedule and test plan.
• Activity: compute the four measures on the reporting cycle; take each one to the forum entitled to act on it.
• Output: control measures page, one page, with the denominators printed.
• Owner: the officer who owns the control set.

4. Deliverables#

Five artefacts, each produced by a step above and named as it will be named in the evidence set. Retention and cadence are organisational choices.

Deliverable	Produced by	Format	Template
Control catalogue	Steps 3.1, 3.2, 3.4	workbook or table, versioned	/templates/control-catalogue
Owner matrix	Step 3.3	columns inside the catalogue	same file, Controls sheet
Evidence schedule	Step 3.5	one row per record	same file, Evidence schedule sheet
Test plan	Step 3.6	one row per control	same file, Test plan sheet
Gap and exception log	Step 3.7	table, cross-referenced to the register	template pending

The Statement of Applicability cross-reference is a column rather than a sixth artefact. Keeping it as a column stops the two documents describing different control sets.

5. What the auditor will ask#

The phrasing follows how an assessor opens: a record first, then the decision behind it.

An assessment that stays inside the catalogue is going well. One that moves to a spreadsheet nobody recognises is where a framework-shaped list fails.

6. Failure modes and how they surface as findings#

Four patterns account for most of the damage: the pattern, the wording it produces, the smallest change that removes it.

The root cause is shared: the catalogue was written to satisfy a document rather than to run controls.

7. Mapping to standards (clause table, verified)#

Provenance for the table. ISO/IEC 27001:2022 clause numbers and titles come from the publisher's contents listing ²⁸. ISO/IEC 27002:2022 controls and clause 4 come from a licensed copy, paraphrased ²⁹. CSF Category identifiers come from Appendix A ¹³.

Catalogue element	ISO/IEC 27001:2022	ISO/IEC 27002:2022	CSF	Evidence sampled
The catalogue itself	8.1 Operational planning and control	clause 4.1 themes; clause 4.3 control layout	ID.AM	Versioned catalogue with a change record
Owner, producer, approver	5.3 Organizational roles, responsibilities and authorities	5.2 Information security roles and responsibilities; 5.4 Management responsibilities	GV.RR	Three filled role columns per row
Segregation between owner and tester	5.3 as above	5.3 Segregation of duties	GV.RR	Owner and tester named separately
Requirement behind each control	6.1.3 Information security risk treatment	—	GV.OC	Register entry or obligation identifier
Policy behind each control	5.2 Policy	5.1 Policies for information security	GV.PO	Approved policy, dated, in the map
Procedure behind each control	7.5 documented information	5.37 Documented operating procedures	PR.PS	Procedure naming the responsible roles
Evidence record and retention	7.5.3 Control of documented information	5.37 as above	PR.DS	Named record, producer, frequency, retention
Monitoring feed	9.1 Monitoring, measurement, analysis and evaluation	8.16 Monitoring activities	DE.CM	Monitoring records over the retention period
Test result	9.1 as above	5.36 Compliance with policies, rules and standards for information security	ID.IM	Result with method, sample and tester
Independent review and internal audit	9.2, 9.2.2 Internal audit programme	5.35 Independent review of information security	GV.OV	Programme, reviewer independence recorded
Failed test to closure	10.2 Nonconformity and corrective action	5.36 as above	ID.IM	Corrective action with an effectiveness review
Supplier-operated controls	8.1 as above	5.19 Information security in supplier relationships	GV.SC	Assessment record per supplier control

One worked row shows the pattern. A backup restore test is a control. Reference control 8.13 expects backup copies of information, software and systems to be maintained and regularly tested against an agreed topic-specific policy ³⁰. Its cross-reference is PR.DS, and its evidence is a dated restore record.

Financial entities carry one further row. Regulation (EU) 2022/2554 requires the ICT risk management framework to include at least the strategies, policies, procedures, protocols and tools needed to protect information and ICT assets ³¹. A catalogue is how that "at least" is demonstrated rather than asserted.

8. Checklist (interactive)#

Each item is observable. "Maintained" is not; a dated row with a named role is one.

• One written rule says what counts as a control, and every row passes it.
• Every row names an owner role, an evidence producer role and an approver role.
• No row names a person.
• Rows where one role holds two of the three are listed, with the compensation recorded.
• Every control carries the requirement that put it there: a register entry or an obligation.
• Reference controls with no operation behind them appear on the gap list, with owners.
• The attribute columns carried are named in a written scheme, with their value lists.
• Every control has an evidence record, a producer, a frequency and a retention period.
• Every control has a test that states what it proves, its method, sample and tester role.
• No control is tested by the role that operates it, or the exception is recorded.
• Test frequency is set from the risk the control carries, not from the calendar.
• Every exception carries an approver and an expiry date, and expired ones are reviewed first.
• Retirements are dated decisions, with the risk reassigned or accepted.
• The catalogue and the Statement of Applicability were reconciled within the last year.
• The four measures are reported with their denominators printed.

Related#

• Building an ISMS people actually use — where the Statement of Applicability comes from.
• From regulation to controls — how the obligation column is filled.
• The security operating model — the decision rights behind the owner column.
• GRC automation patterns — control mapping as data, once the catalogue is stable.
• Template: Control catalogue.

References#

Primary sources only. ISO/IEC 27001:2022 clause titles come from the publisher's contents listing; ISO/IEC 27002:2022 clause 4 and control text, and ISO 31000:2018 clause 6.5.3, from licensed copies, paraphrased.

1. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. Contents and clause titles read at https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ²⁸
2. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. Clause 3.1.8 and clause 4, and controls 5.1, 5.2, 5.3, 5.4, 5.19, 5.35, 5.36, 5.37, 8.8, 8.13 and 8.16 read in a licensed copy; catalogue entry at https://www.iso.org/standard/75652.html ²⁹
3. ISO. Risk management — Guidelines. ISO 31000:2018. Clause 6.5.3 read in a licensed copy; catalogue entry at https://www.iso.org/standard/65694.html ³
4. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024. Appendix A read at https://doi.org/10.6028/NIST.CSWP.29 ¹³
5. European Parliament and Council. Directive (EU) 2022/2555 (NIS 2 Directive). OJ L 333, 27.12.2022, p. 80. Article 21 read at https://publications.europa.eu/resource/celex/32022L2555 ³²
6. European Parliament and Council. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. OJ L 333, 27.12.2022, p. 1. Articles 6 and 9 read at https://publications.europa.eu/resource/celex/32022R2554 ³³
7. European Parliament and Council. Regulation (EU) 2024/2847 (Cyber Resilience Act). Annex I Part I read at https://publications.europa.eu/resource/celex/32024R2847 ¹⁹

Cadences, sample sizes, retention periods and thresholds above are organisational choices, not requirements of any standard named.

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.