6.7.5 Accountability measures

What this heading covers

Attribution needs identity, time and context. A log line with a shared service account attributes nothing. The measure is about the proportion of actions that can be traced to a person or a system with a named responsibility. It differs from non-repudiation: accountability does not need a cryptographic proof, but it does need a reliable identity and a record that cannot be silently rewritten.

Record position: family 24 of 40 in clause 6, under 6.7 Security, which carries 6 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.7.5 in the public contents; the text behind it is not public.

How a measure for this family is built

Count the recorded actions that carry a unique actor, a time and the object acted on as the numerator over the actions in scope. Audit a sample against the identity provider to confirm the actor existed and was authorised. Report shared or system accounts separately, because they break attribution.

What to put in place before publication

1. Name the fields that make an action attributable, and test the schema.
2. Report actions under shared accounts as unattributable.

Evidence to keep

Two questions to ask

• Which fields make an action attributable in the record?
• How are actions under shared or system accounts reported?

Where teams usually fall short

• A log that records the service account for every action, so nobody is accountable.

What the number cannot tell you

It cannot tell you whether the actor was authorised. Attribution and authorisation are different questions, and the record only answers the first.

What happens next

Authenticity is about proving the entity is who it claims, which is the input accountability depends on.