Governance Roles and Responsibilities
5 roles in a customer contract, one name typed into all 5 boxes, and the fix that took an afternoon.
// @18xBan · GRC Series · Chapter 15
Who decides, who does, who signs, and who covers when they're away.
Monday, 9:15 AM: one name, 5 Boxes
Gotham Mutual's contract arrives with a security schedule attached. Most of it is familiar. Section 4 is a table:
Supplier shall identify, by name and contact details:
(a) the individual accountable for information security;
(b) the individual accountable for privacy compliance;
(c) the incident response lead;
(d) the 24/7 security contact;
(e) the individual authorised to accept security risk on Supplier's behalf.
Dan forwards it with the boxes already filled in. Your name is in all 5.
He isn't being lazy. He's doing what feels obvious: there's one security person, so the security person is all of it. But look at what those 5 boxes actually claim.
Box (e) says you can accept risk on Wayne's behalf which contradicts the delegation bands approved last month, where anything over $250k or touching customer data goes to Maya. Box (b) claims you're accountable for privacy compliance, which under PIPEDA is a specific designation with its own rules. Box (d) promises a 24/7 contact from a company with one security hire and no on-call rota.
Every one of those is a commitment Wayne would be audited against, in a contract worth $1.8M.
5 roles, 1 name, and 3 commitments Wayne can't actually keep.
The unpopular truth: if one name fits in every governance box, you don't have a governance structure. You have a single point of failure with a job title, and a contract that turns it into a liability.
The small failure that made the case
While you're drafting the reply, something else lands.
An engineer needed a temporary exception last week to keep a legacy integration running past its deprecation date. It touched a copy of customer records. Under the bands approved in March, that's Dan's to accept customer data, 60 days maximum.
It was approved by you. You approved it because you were the one who noticed, and because nobody had written down who approves what in a way anyone could look up. The bands existed in a document that 5 people have read once.
Nothing bad happened. The exception was reasonable. But the approval is invalid, and the fix is 2 emails and a re-approval by Dan, which is exactly the kind of small, boring failure that convinces a CTO that a roles document is worth an afternoon.
The right decision, signed by the wrong person, because nobody could look it up.
Responsible, accountable, and the difference that matters
Everyone has seen RACI. Fewer people apply the one rule that makes it useful.
| Term | Means | Can it be delegated? |
|---|---|---|
| Accountable | The person who answers for the outcome. One per decision | No. You can delegate the work, never the answering |
| Responsible | The person who does the work | Yes |
| Consulted | Whoever has to be asked before the decision | Yes |
| Informed | Whoever needs to be told after | Yes |
The reason this matters at Wayne's size: you can be responsible for almost everything and accountable for very little, and that's the correct arrangement. Dan accepts security risk on Wayne's behalf. You recommend, operate, test and report. When a decision needs an owner who isn't you, the document has to be able to say so out loud.
You can delegate the work. You can never delegate the answering.
ISO 27001 Clause 5.3 puts the obligation on top management: ensure that responsibilities and authorities for relevant roles are assigned and communicated. NIST CSF 2.0 GV.RR-02 goes a step further roles, responsibilities and authorities are to be established, communicated, understood and enforced. Understood and enforced is the part most small companies fail, because the document exists and nobody can quote a line of it.
Define roles, then map people
The trick that makes this survive turnover: write the role, then assign a person. 2 columns, not one.
If the document says "Priya approves production access," it breaks the day Priya changes jobs. If it says "Production Access Approver: held by the Engineering Lead, currently Priya Nair, deputy: Head of Security," it survives.
Field by field: a role definition
| Field | What goes in it |
|---|---|
| Role name | The role, not the person |
| Purpose | One sentence on why the role exists |
| Held by | The person today, with their job title |
| Deputy | Who acts when the holder is away or conflicted |
| Authority | What this role may decide alone |
| Limits | What it may not decide, and who that goes to |
| Consulted | Who must be asked first |
| Recorded where | Where decisions by this role are written down |
| Review | When the assignment is re-confirmed |
The 2 fields people skip are Limits and Deputy, and they're the ones that get tested. Limits is what stops a role quietly expanding until it can approve its own work. Deputy is what stops a company having a governance outage every time somebody takes 2 weeks off.
Write the role, then name the person. 9 fields, one page each.
Wayne's governance roles
7 roles, filled honestly.
| Role | Held by | Deputy | Authority | Limits |
|---|---|---|---|---|
| Accountable executive for security | Dan (CTO) | Maya (CEO) | Accepts security risk up to the medium band; approves topic policies | Anything over $250k or customer data goes to Maya |
| Head of Security | You | Dan, for operational tasks | Recommends, operates, tests, reports; accepts low-band risk | Cannot accept risk touching customer data or admin access |
| Privacy accountable individual (PIPEDA) | Dan (CTO) | You, delegated for day-to-day | Answers for privacy compliance; named in the privacy policy | Cannot delegate accountability, only the work |
| Incident commander | You | Priya | Declares an incident; directs the response; decides customer notification timing with Dan | Cannot decide regulatory notification alone |
| Production access approver | Priya (Engineering Lead) | Dan | Approves standing and temporary production access | Cannot approve her own access |
| Vendor security approver | Dan | You | Approves new vendors after review; tiers them | No approval before the review completes |
| Policy approver | Maya (umbrella), Dan (topic policies) | — | Approves and re-approves policies | Standards are approved by the control owner |
2 honest notes go at the bottom of the page, because hiding them helps nobody:
You are both first and second line for identity controls. Documented in the assurance map, compensated by Priya re-performing the numbers.
Wayne has no independent internal audit function. Outsourced for February. The deputy column for the Head of Security role reads "Dan," which is a real gap for anything requiring independence.
Note who isn't in the privacy row: you. PIPEDA Principle 4.1 says an organisation must designate an individual or individuals accountable for compliance with the principles, 4.1.1 says accountability rests with the designated individual even when others do the day-to-day work, and 4.1.2 says the identity of that person must be made known on request. Delegating the work to you is fine and normal. Delegating the accountability isn't a thing.
7 roles, 7 limits, and 2 gaps written down rather than hidden.
Decision rights: the table people actually use
The role definitions are the reference. The decision rights table is what gets pinned in the team channel, because it answers the question people ask at 4pm on a Thursday: who says yes to this?
| Decision | Recommends | Approves | Consulted | Recorded in |
|---|---|---|---|---|
| Accept a low-band risk | You | You | Dan | Risk register |
| Accept a medium-band risk | You | Dan | Priya, if it touches delivery | Risk register |
| Accept anything touching customer data | You | Maya | Dan | Risk register + management review |
| Grant standing production access | Requesting lead | Priya | You | Access request ticket |
| Grant temporary admin access | You | Priya | — | Ticket, with expiry |
| Approve an exception under 90 days | Engineer | You (low) / Dan (medium) | — | Exception register |
| Approve a new vendor | You | Dan | Priya, for integrations | Vendor register |
| Declare an incident | Anyone | You (incident commander) | — | Incident record |
| Notify a customer of a security issue | You | Dan, with Maya for material issues | Legal counsel | Incident record |
| Approve a policy | You | Maya (umbrella) / Dan (topic) | Owner | Policy register |
| Sign a customer security commitment | You | Dan | Maya, over $500k contract value | Contract file |
That last row is the one that would have caught Monday's problem before it left the building.
The unpopular truth: "everyone is responsible for security" is a slogan that guarantees nobody holds a decision right. A decision with two approvers is a decision with none, and a decision with no named approver goes to whoever is most confident in the room.
Checking the table for holes
Before publishing, run the obvious checks. They take a minute and catch the things people argue about later.
# roles-check.py — gaps a governance table shouldn't have
DECISIONS = [
# decision, recommends, approves, roles that can't be both
("Low-band risk", "You", "You", True),
("Medium-band risk", "You", "Dan", False),
("Customer-data risk", "You", "Maya", False),
("Standing prod access", "Lead", "Priya", False),
("Exception (low)", "Engineer", "You", False),
("New vendor", "You", "Dan", False),
("Declare an incident", "Anyone", "You", False),
("Customer notification", "You", "Dan", False),
("Policy (umbrella)", "You", "Maya", False),
]
DEPUTIES = {"You": "Dan", "Dan": "Maya", "Priya": "Dan", "Maya": None}
for decision, recommends, approves, self_approval in DECISIONS:
flags = []
if self_approval:
flags.append("SELF-APPROVAL")
if not approves:
flags.append("NO APPROVER")
if DEPUTIES.get(approves, "missing") is None:
flags.append("NO DEPUTY")
print(f"{decision:<26} {recommends:>9} -> {approves:<6} {' '.join(flags) or 'ok'}")
Low-band risk You -> You SELF-APPROVAL
Medium-band risk You -> Dan ok
Customer-data risk You -> Maya NO DEPUTY
Standing prod access Lead -> Priya ok
Exception (low) Engineer -> You ok
New vendor You -> Dan ok
Declare an incident Anyone -> You ok
Customer notification You -> Dan ok
Policy (umbrella) You -> Maya NO DEPUTY
Sample output (illustrative). Wayne Industries is fictional.
Two flags, and both get a decision rather than a fix.
Self-approval on low-band risk stays, deliberately, with a compensating control: every low-band acceptance is listed in the monthly pack that Dan reads. At Wayne's size, sending every minor acceptance to the CTO would mean nothing gets accepted at all.
No deputy for Maya is real and can't be solved internally there is nobody above the CEO. The documented answer is that if Maya is unavailable for more than 5 working days, customer-data decisions wait, and the risk of waiting is itself recorded.
Writing "we chose this, and here's what compensates" beats leaving a blank every time.
2 flags, 2 decisions, 0 blanks.
Back to the contract
The reply to Gotham takes 20 minutes once the table exists:
(a) Accountable for information security: Dan Okafor, CTO. You are named as the operational security lead and day-to-day contact.
(b) Accountable for privacy compliance: Dan Okafor, CTO, as Wayne's designated individual under PIPEDA, with you delegated for day-to-day handling.
(c) Incident response lead: you, deputy Priya Nair.
(d) 24/7 security contact: this one gets negotiated rather than answered. Wayne offers a monitored security inbox, a 1 hour acknowledgement target during business hours, and a 4 hour target outside them via an on-call phone shared between you and Priya. Honest, and deliverable.
(e) Authorised to accept security risk: Dan for medium and below, Maya for anything involving customer personal data or over the high threshold, exactly as the delegation table says.
Gotham's analyst accepts (d) with a minor edit. She has read enough vendor schedules to know that "24/7" from a 240-person company usually means "one person's mobile, and they're asleep."
5 different names, 1 negotiated clause, 0 promises Wayne can't keep.
Evidence #15
The roles and responsibilities document: seven roles, each with authority, limits and a deputy.
The decision rights table, pinned in the team channel and linked from the policy set.
The two documented gaps, with what compensates for each.
Dan's re-approval of last week's exception, with a note on why the original approval was invalid.
The contract schedule as submitted, with the negotiated response clause.
Approval recorded at the management review, with the next re-confirmation in six months.
Evidence #15: assigned and communicated roles and authorities, plus evidence they were applied to a real decision and a real contract.
Approved, pinned, and cited within a week.
What an auditor accepts vs rejects
| Accepted | Rejected |
|---|---|
| Roles defined separately from the people holding them | A list of names with no defined authority |
| One accountable person per decision | Two approvers, or "the team decides" |
| Limits written for every role | Authority with no stated ceiling |
| Named deputies | A structure with a single point of failure and no acknowledgement of it |
| Evidence the table was used | A document approved once and never cited |
| Conflicts documented with compensating controls | Conflicts nobody mentioned |
| Communication evidence: channel post, onboarding, acknowledgement | "Everyone knows who does what" |
What you actually do on Monday
List the ten decisions your company actually makes about security. Start with the ones that caused an argument.
Name one approver each. If you can't, that's the finding.
Write the limits before the authorities. It's easier, and it's what people test.
Add deputies. Any role without one is a planned outage.
Separate role from person in every line of the document.
Pin the decision table where the work happens, not in a policy folder.
Check for self-approval, and either remove it or write the compensating control.
Get it approved by top management and re-confirmed on a schedule.
Framework mapping
Roles and authorities, as each framework asks for them.
Maturity ladder
| Stage | 20 people | 200 people | 2,000 people |
|---|---|---|---|
| The document | One page: 5 roles, five limits | Role definitions plus a decision rights table | Authority matrix, cascaded per business unit |
| Deputies | The founder covers everything, stated | Named deputy per role | Formal succession and delegation records |
| Communication | A pinned message and a line in onboarding | Onboarding, policy set, annual acknowledgement | Role-based training with attestation |
| Conflicts | Acknowledged in writing | Compensating controls documented | Segregation enforced by tooling |
| Review | When someone joins or leaves | Every six months, and on org change | Continuous, with HR system integration |
At 20 people the honest version is: "the founder is accountable for everything, and here are the three decisions they've delegated." Written down, that passes. Unwritten, it fails the first customer questionnaire.
Where Wayne sits: 7 roles defined, limits and deputies assigned, 2 conflicts documented with compensating controls, and a contract schedule answered with 5 different names instead of one.
Cheatsheet
Who decides what, on one page.
The takeaway
Write the role, then name the person. Roles outlive people. Every decision needs exactly one approver, and every role needs a limit and a deputy. Document the conflicts you're choosing to keep, with what compensates for them. The test is a Thursday afternoon: can someone look up who says yes, without asking you?
⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice validate against your own auditor and jurisdiction.