Accountability is the property that any meaningful action in a system can be traced back to the identity responsible for it, with evidence strong enough to stand up to scrutiny. Authentication establishes who an actor is and authorization decides what they may do; accountability records what they actually did, so the system can later answer "who did this, and can we prove it?" Without it, a breach, a mistake, or a dispute becomes a guessing game.
What logging, auditing, and non-repudiation each add#
These three words are often used loosely, but they describe different strengths of evidence, each building on the one before it.
| Mechanism | What it produces | What it still cannot do |
|---|---|---|
| Logging | A timestamped record that an identity performed an action | Prove the record was not altered afterward |
| Auditing | Independent review of the collected records to establish what actually happened | Stop the actor from claiming the account was not theirs |
| Non-repudiation | Cryptographic proof binding a specific actor to the action | Help if the actor's signing key was stolen |
A plain log entry is a claim; auditing reviews and corroborates that claim; non-repudiation makes it hard to deny. Each layer costs more to build, so most systems log everything, audit the security-relevant subset, and reserve non-repudiation for high-stakes acts such as contracts, payments, and code releases.
Tracing a fraudulent wire transfer#
Suppose a finance team discovers an unauthorized payment left the company account. Accountability turns that alarm into a trail an investigator can follow:
- The payment system logs the transfer, recording the amount, the recipient, the time, and the account
a.oseithat approved it, rather than a sharedfinancelogin. - The identity provider log shows
a.oseiauthenticated with a hardware key minutes earlier, from an unusual country. - Clocks agree, because every system syncs to the same trusted time source, so the sign-in and the approval line up in the correct order.
- The approval carried a digital signature, so the actor cannot plausibly claim someone fabricated the request on their behalf.
The trail now points at one account and one moment. Note what it does not yet prove: the entries identify an account, not a person, so stolen credentials or a hijacked session would look the same. Remove any single link, such as a shared login or logs stored on the breached server itself, and the trail collapses into a shrug.
The tension with privacy and data minimization#
Accountability pulls toward recording more; good privacy practice pulls toward recording less. The resolution is not to log everything "just in case." That bloats storage, buries real signals in noise, and turns audit trails into a sensitive dataset of their own, a tempting target and a compliance burden. The discipline of minimization applies here too: decide in advance which events are security-relevant, capture those consistently, protect them, and set a retention window that serves investigation and regulation without hoarding. Narrow access under least privilege eases the trade-off, because fewer people can perform any sensitive action, so the list of plausible actors is short before a single log is opened.
Where it reinforces the other principles#
Accountability rests on authentication and authorization, since a trail is only as trustworthy as the identities it names. It is cheapest when planned from the start, which makes it a concern of security by design rather than a bolt-on, and architectures built on zero trust naturally emit the per-request records that attribution depends on.