Few distinctions in governance do as much work as this one, and few are blurred as casually in everyday speech. In ordinary conversation "accountable" and "responsible" are synonyms. In governance — and on every ISACA and ISC2 exam — they are different roles, and confusing them produces wrong answers on paper and orphaned risks in real organisations.
The definitions, sharpened
Responsibility is the obligation to perform — to do the task, operate the control, execute the process. It attaches to the doer, and it can be assigned, shared and delegated. The administrator who applies patches is responsible for patching.
Accountability is the obligation to answer — for outcomes, to a higher authority, regardless of who did the work. It attaches to the owner, it sits with exactly one party per outcome, and it cannot be delegated. The CIO who answers to the board for system security remains accountable whether patching was done by staff, a contractor or a managed service.
Responsibility flows down with the work. Accountability stays put with the owner. Every governance structure that functions is built on that asymmetry.
The asymmetry is the whole point. If accountability could be delegated, every failure would dissolve into a chain of "I handed that off." Governance frameworks pin accountability precisely so that someone always answers — which is why boards can outsource operations but never their duty of oversight, and why a data controller answers to the regulator for a processor's breach.
RACI, used correctly
The RACI model operationalises the distinction: Responsible (does the work — one or more), Accountable (answers for the result — exactly one), Consulted (provides input), Informed (told of outcomes). Two rules carry all the value. One A per row, always; two accountable parties means none. And A is not "the most senior person nearby" — it is the person with authority to make the outcome happen, because answering without authority is scapegoating, and authority without answering is unchecked power.
A RACI chart with three A's in a row, or rows with no A at all, is not a documentation defect. It is a live risk: an outcome nobody owns.
Where the distinction bites in practice
Outsourcing and cloud. Tasks transfer; accountability does not. Your cloud provider is responsible for the hypervisor's security; you remain accountable to your customers and regulators for your data on it. Under privacy regimes from GDPR to India's DPDPA the pattern is explicit: the controller/fiduciary answers for processing even when processors perform it. Contracts allocate responsibility and remedies — they cannot move statutory accountability.
Risk ownership. The risk owner is the accountable party for a risk — typically the manager of the business area where the risk lives. The risk function facilitates, challenges and reports (responsible for the process), but it never owns the business's risks. Any structure where "risk owns the risks" has quietly relieved the business of answering for its own decisions.
Security operations. A CISO may be accountable for the security program while engineers are responsible for its controls. When a control fails, the engineer answers for the task; the CISO answers for the program that allowed the failure mode; and above both, executive management remains accountable for resourcing the program adequately. Three layers, no contradiction — as long as each is named.
How exams test it
CRISC, CISM and CISSP all probe the distinction with scenario questions where the trap option delegates accountability:
- "After outsourcing X, who is accountable for its security?" — the organisation/owner, never the vendor. The vendor is responsible per contract.
- "Who should own this risk?" — the business/process owner where the risk resides, not the risk function, not the CISO, not audit.
- "Senior management has delegated security tasks to a committee — what remains with senior management?" — accountability, by definition.
- Any option in which accountability "transfers," "is shared equally," or "moves to the third party" is structurally wrong before you read the rest.
One sentence to carry into the exam room and the steering committee alike: you can delegate the doing, never the answering. Hold it firmly and a remarkable amount of governance — RACI design, outsourcing clauses, risk registers, board reporting — assembles itself around it.