Governance structures, and who is allowed to decide

Objective 5.1 in this course covers security governance — CompTIA's scope note for it summarises guidelines, policies, standards, procedures, external considerations, monitoring, governance structures and roles and responsibilities. This lesson takes the structures and the roles; the document hierarchy is the next lesson.

Why this matters

Domain 5 is 20% of SY0-701 — a fifth of the exam, more than Security Architecture. It reads as paperwork to people who came for the technical material, which is exactly why candidates lose marks here disproportionately.

The questions are not hard. They are about who decides and what a thing is called, and both are learnable in an afternoon. The trap is not difficulty, it is dismissal.

The lesson

Boards, committees, government entities and centralised versus decentralised

Governance is the system by which an organisation directs and controls itself: who sets the objectives, who decides what risk is acceptable, and who holds people accountable for it. Security governance is that applied to security, and its defining feature is that it sits above the security team — security implements, governance decides.

The structures CompTIA names:

• Boards. The board of directors carries ultimate accountability. In most jurisdictions that is now explicit for cyber risk, and it cannot be delegated: a board may delegate the work, never the accountability.
• Committees. A security or risk committee, usually a subset of senior management, meeting regularly to review risk, approve policy and decide on exceptions. This is where the risk register from 5.2 is actually reviewed.
• Government entities. Regulators, national cyber security bodies and sector authorities that impose requirements from outside. They are governance input you do not control.
• Centralised versus decentralised governance — one central authority setting policy for the whole organisation, or business units setting their own. The trade is exactly the one from Domain 3: centralised gives consistency and auditability and can be slow and badly fitted to local needs; decentralised gives responsiveness and produces drift and inconsistent protection.

The point the exam draws out: governance decides risk appetite, and everyone below implements against it. A security team that makes risk decisions on its own is doing governance's job without governance's authority — and when a decision to accept risk goes wrong, the question asked afterwards is who was authorised to accept it.

Owners, controllers, processors, custodians and stewards

The roles, which are examined as definitions and as scenario matching.

• Data owner. Accountable for a data set: its classification, who may access it, and its retention. A business role, normally a senior person in the department the data belongs to — not IT.
• Data controller. A privacy-law term: the party that determines the purposes and means of processing personal data. The controller carries the legal obligations to the data subject.
• Data processor. Processes personal data on the controller's behalf and on the controller's instructions. Most of your SaaS vendors are processors. A processor that decides its own purposes for the data has become a controller and has taken on the obligations.
• Data custodian. Implements and operates the controls the owner specifies — backups, access provisioning, storage. Usually IT.
• Data steward. Responsible for data quality, meaning and appropriate use; the one who knows what the fields mean and whether a use is consistent with why it was collected.
• Data subject. The individual the personal data is about.
• Privacy officer / DPO. Accountable for the privacy programme and the contact point for regulators and data subjects.

The distinctions the exam actually tests:

• Owner decides, custodian implements. If a scenario has the storage administrator deciding who may see a data set, the roles have collapsed and that is the finding.
• Controller instructs, processor follows. In a breach at a vendor, the controller usually still owes the notification duty to the data subjects, which is why the contract terms in 5.3 matter so much.

Two more governance roles worth having: RACI as the mechanism for recording who is responsible, accountable, consulted and informed for a given activity — with the rule that there is exactly one accountable party; and the distinction between responsible (does it) and accountable (answers for it), which is a favourite distractor.

External considerations: regulatory, legal, industry, local, national, global

Governance takes inputs from outside, and CompTIA lists them by scope:

• Regulatory — rules from a sector regulator, with the power to fine, sanction or withdraw a licence.
• Legal — statute and case law, including contract law, computer misuse and employment law.
• Industry — standards a sector imposes on its participants. PCI DSS is the canonical example: not a law, and non-compliance can cost the ability to process card payments, which is more immediate than most laws.
• Local, regional, national and global — the same activity can be governed at several levels at once, and the rules can conflict. A global organisation may face a national requirement to retain data and another jurisdiction's requirement to delete it on request; resolving that is a legal decision, and the security team's job is to surface it rather than to pick.

The practical governance consequence: you need a register of obligations — which rules apply to which part of the business — because compliance you do not know you owe is compliance you are failing. That register feeds the compliance monitoring in 5.4.

Monitoring and revision, and the policy nobody has read since 2019

Governance is continuous, and the two activities CompTIA names are the ones organisations skip.

Monitoring asks whether the governance is working: are policies being followed, are exceptions growing, are the controls the policy requires actually present, is the risk register current, are the metrics moving.

Revision is updating the governance when reality changes — new regulation, a new business line, a merger, a new technology, or an incident that showed the policy was wrong.

The failure in the heading is the common one. A policy written years ago, approved once, never reviewed, referring to systems that no longer exist and practices nobody follows. It is worse than no policy, for two reasons the exam cares about: staff learn that policy is decorative, which undermines every policy; and an auditor or a court will hold you to what it says, including the parts you stopped doing.

The controls are unglamorous: every policy has an owner and a review date; review is scheduled rather than event-driven; version and approval history is recorded; and the current version is where people can find it. "Reviewed annually and re-approved" is a real audit requirement and a reasonable exam answer.

Mapping a scenario to the role that owns the decision

The exam's shape here is a scenario and "who should do this?". A short method:

1. Is it a decision about the data itself — who may see it, how long it is kept, how it is classified? That is the data owner.
2. Is it implementing a control — configuring the backup, granting the access, encrypting the store? That is the custodian.
3. Is it about personal data and the purpose it is used for? Controller. Acting on someone else's instructions with it? Processor.
4. Is it accepting risk? That belongs to whoever governance has authorised — a risk owner, a committee, or the board depending on magnitude. Never the analyst who found it.
5. Is it about what the data means or whether a use is appropriate? Steward.
6. Is it approving a change? The change advisory board from Domain 1.

And the habit that answers the residual cases: ask who answers for it if it goes wrong. Accountability does not move, and the correct answer is almost always the person who would be asked that question.

What to take into the exam

• Governance sits above the security team and sets risk appetite; security implements against it.
• Owner decides, custodian implements. Controller determines purpose, processor follows instructions.
• In a vendor breach the controller usually still owes notification to the data subjects.
• Exactly one party is accountable in a RACI; responsible means does the work.
• PCI DSS is an industry standard, not a law, and its sanction — losing card processing — is often faster than a regulator's.
• A policy with no owner and no review date is an audit finding and a liability, because you are held to what it says.