CCSP: Auditability of Data Events, Chain of Custody and Non-Repudiation

A data event is any action on data that a system can record: a read, a change, a deletion, an export, a permission change on a data store, or a failed attempt at any of these. Auditability means those events are recorded completely and reliably enough that an independent party can review them; traceability means an action can be followed back through every system it touched to the request that caused it; accountability means each action can be tied to the one identified party answerable for it. Two further properties turn records into evidence: non-repudiation (the originator cannot credibly deny the action) and chain of custody (the evidence can be shown to be what was collected).

CCSP sub-domain 2.8 covers three skills: defining event sources and the attributes each event must carry, logging, storing and analysing data events, and chain of custody and non-repudiation. The forensic collection process itself belongs to sub-domain 5.4, security operations and SIEM to 5.6, and retention policy design to 2.7; this lesson covers how they apply to data-event records.

Data events come from several distinct sources, and the most common mistake is assuming the provider's default audit log covers them. It usually does not. Provider audit logs separate two kinds of activity:

• Management-plane (control-plane) events: operations on resources, such as creating a storage bucket, changing an access policy, resizing a database or deleting a virtual machine. These are typically recorded by default.
• Data-plane events: operations on the data inside the resources, such as reading an object, querying rows or downloading a file. Because they are high-volume, providers usually record them only when object-level or data-access logging is explicitly enabled, often at extra cost.

An investigation that relies only on default logging can therefore show exactly who changed a bucket policy and nothing about which objects were later read. Other sources fill different gaps:

Who owns each source depends on the service model

The shared-responsibility split decides who can produce each event record:

• IaaS: the customer installs and runs the operating system and applications, so application and database events are the customer's to configure. The provider supplies the management-plane log; its own infrastructure telemetry stays internal.
• PaaS: the customer has no access to the underlying host, so its own instrumentation stops at the service boundary. Managed databases and storage normally offer a built-in audit capability that is usually off by default; the customer must turn it on and route its events to retained storage. Records of changes to the resource itself never describe what was done to the data inside it.
• SaaS: the customer cannot instrument the platform at all, so the provider's audit log is the only complete record of in-application data events. What the customer gets (which events, which attributes, how long the console keeps them, and whether they can be exported by API into the customer's own tooling) is decided by the product and the contract. Secure these terms before the platform goes live, not during an investigation. Assurance about how the provider runs its own controls is a different thing from receiving your own tenant's event records, and any tool placed between users and the service sees only what it is routed or granted.

Start from requirements, not from the available logs. Regulations, contracts, the data's classification and the questions investigators will need to answer determine which events (access, change, export, permission changes, failures) and which attributes must be captured. Only then do you select and configure sources, choose analysis tooling and design protected storage. Turning everything on at maximum verbosity is expensive, buries the important events in noise, and still does not guarantee that the needed attributes are recorded.

Scope full data-event logging by classification

Object-level logging everywhere can multiply logging costs. The defensible way to control cost is to use the classification already done in sub-domain 2.5: enable complete data-event logging on stores that hold regulated or high-sensitivity data, and rely on cheaper management-plane logging for lower classifications. Thinning what is captured inside a regulated store is the wrong lever. Completeness is the property an investigation depends on, data theft shows up as reads rather than changes, and record types that describe connections or resource configuration do not carry the actor and object attributes a data event needs.

Logs record events, not the sensitive data itself

A log is a data store in its own right, usually with wider access and longer retention than the system it describes. Writing full request bodies, passwords or card numbers into logs copies regulated data into it; PCI DSS, for example, requires stored card numbers to be rendered unreadable and forbids keeping sensitive authentication data after authorisation. The root-cause fix is in the log design: record what happened, by whom and to which object, while redacting or tokenising protected values at the point the entry is written. Controls applied to the log store afterwards protect a copy that should never have been made; they do not remove it.

When identities in the logs are themselves the privacy concern, pseudonymisation balances the two needs: names are replaced with consistent tokens so analysts can still follow one person's activity, while the re-identification mapping is held separately under restricted access for authorised investigations. Irreversible anonymisation, or recording only a role, destroys the attribution accountability depends on.

Every data event must answer who, what, when, where, on which object, and with what outcome. A minimal useful record carries the actor's identity, the action, a synchronised timestamp, the source address (and derived geolocation, if used), the target data object, and success or failure. Each attribute establishes something different, and none substitutes for another.

Identity: the attribute that creates accountability

Only the identity attribute names the party answerable for an action; address, location and time describe the request, not the actor. Accountability therefore requires a unique identity per person or service:

• Shared accounts defeat it. If several administrators use one login, every event names that login and nobody can be held to an action. The fix is individual named accounts and retiring the shared one. Hardening the shared login or enriching its records improves other properties, but none of that makes the actor unique.
• Shared roles need the originating identity carried through. When many federated users assume one cloud role, the log shows only the role. Have federation stamp each assumed-role session with the individual who requested it (for example in the session name or a session tag), so every event recorded under the role still names a person. Federation itself stays; it is the session metadata that changes.
• Service identities identify the service, not the request. In microservices, the account each service uses to call the next shows which service acted, not which user's request caused it; that needs a correlation ID (see analysis, below).

IP address: where the request came from, as seen by the system

The source IP address is the address of whatever opened the connection, which may not be the client. Behind a load balancer or reverse proxy, servers see the intermediary's address; the original client address travels in a forwarded header (the standard Forwarded header defined in RFC 7239, or the widely used de facto X-Forwarded-For), and the application should log it, trusting the header only when it arrives from the known balancer, because a client can forge it. NAT, proxies and VPN gateways likewise replace the user's own address. Network flow logs between the balancer and servers still show the intermediary.

Geolocation: an estimate of the address, not the person

IP-derived geolocation maps address ranges to approximate places. What it yields is an estimate of where a network address sits, not where the person is, where the data is stored or which provider region served the request. A request through a corporate VPN or anonymising proxy appears at the exit point. Geolocation is valuable for anomaly detection, such as impossible travel, but an anomaly is a lead to be resolved, not a verdict: correlate it with VPN gateway and identity-provider sign-in logs (session, device, gateway) before acting either way. Better lookup data sharpens the estimate of the address; it never turns it into a fact about the person.

Timestamp: synchronised and in UTC

Investigations merge events from identity providers, applications, databases and storage into one timeline. If each source keeps its own drifting clock, the merged timeline shows effects before causes (a download before the sign-in), with a gap that differs per source. Two controls are needed together:

• Synchronise every source to a common time reference (for example NTP), which fixes drift.
• Record in UTC (or with an explicit offset), which fixes representation: local time repeats an hour when daylight saving ends, so two different instants share one label even on perfectly synchronised clocks.

The ordering key must be the moment each event occurred, measured on a synchronised clock. Any other key either adds transport delays or is meaningful only inside a single system.

Stored logs must be protected from the people they record. A privileged administrator who can modify or delete the log of their own actions makes the log worthless as evidence, so the controls focus on separation of duties, then immutability, then verifiable integrity.

• Separate log account or tenant. Deliver logs to a log-archive account administered by a different team (typically security). Any protection configured inside the production account remains under the control of the administrators it is meant to constrain.
• Write-only delivery. Least privilege for each workload's delivery identity is permission to write new log objects only, with no read, overwrite or delete. Retention deletion is done by the store's owner through lifecycle rules, and read access goes to investigators in the security account.
• Immutability. Write-once (WORM) retention locks prevent alteration and deletion for the retention period.
• Signed, hash-chained digests. A periodic digest records the hash of each delivered log file and the hash of the previous digest, and is digitally signed.

Preventing tampering and demonstrating that nothing was tampered with are different requirements:

Strong designs combine them: a separate account, write-only delivery, immutable storage and signed digests.

How long to keep data-event logs

Logs that contain user IDs and IP addresses hold personal data, so privacy law limits how long they are kept. Under the GDPR's storage limitation principle, personal data is kept no longer than its purpose requires; set each log category's retention from its own documented requirement (an access-record regulation, an investigative need defined by counsel, an operational need for debug traces) and delete securely at the end. Indefinite or blanket retention has no documented purpose to justify it, and controls that change how logs are stored do not answer how long they may be kept. Equally, cutting retention below a documented need breaks that need.

Storage limitation does not override a legal record-keeping duty. GDPR allows processing that is necessary to comply with a legal obligation, and the period that obligation sets is the necessary period: keep the records that long, document why, restrict who can read them, and delete when it ends. Stripping identities out before the period ends defeats the purpose the obligation gave the records. Retention policy design in general is taught in sub-domain 2.7.

Analysis turns events from many sources into answers, and it depends on the events being joinable. Collecting logs in one place is necessary but not sufficient; three things make them joinable:

• Normalisation to a common schema. Different services record the same person as an email address, a directory principal name or a numeric account ID. Normalising events to one schema, with each source identifier mapped to a canonical user (for example through the identity provider's directory), is the first step that lets one person's activity be followed across services. Per-source dashboards entrench the split.
• Correlation (trace) IDs. In a distributed application, each service logs its own events with its own request ID, so an incorrect change in one service cannot be tied to the request that caused it. Generating one correlation ID at the entry point (for example the API gateway) and passing it in every downstream call gives each log entry a common key back to the originating request and its user. Central storage and clock synchronisation are complementary but do not create that link.
• Consistent time. Synchronised UTC timestamps (above) let events be ordered across sources.

Once events are normalised and correlated, they feed alerting and investigation (for example a SIEM) and support the anomaly detection described earlier. Running the security operations centre and its tooling is covered in sub-domain 5.6.

Non-repudiation is the assurance that the party who performed an action cannot later credibly deny it, backed by evidence that holds up before a third party such as an arbitrator or court. It goes beyond its neighbours: integrity shows data was not changed, authentication verifies an identity at the moment of access, and accountability traces actions to an identity. Non-repudiation adds proof of origin that survives with the record.

The standard mechanism is a digital signature made with a private key under the signer's sole control. The comparison below is the distinction most often tested:

Sole control is the condition. If signing keys sit on a shared server that many administrators can operate, a valid signature proves only that someone with access to that server signed. The record's integrity is still provable, but the named signer can plausibly deny the action. Surrounding the signature with extra evidence helps an investigation, but nothing added afterwards restores sole control. Keys for non-repudiation are therefore held by the individual (for example on a personal token or HSM-backed credential the individual alone can unlock), not by a shared service.

A chain of custody is the documented, unbroken record of who held a piece of evidence, when, for what purpose and what they did with it, from collection to presentation. Its job is to show that the evidence presented is the same as the evidence collected. Records about how evidence is protected, preserved or where it originated are related, but they are not the custody record: custody is about handling.

Hashes make the chain testable

At the moment of collection, compute and record a cryptographic hash of each evidence file (for example exported audit logs). Whenever the evidence is used, recompute the hash; a match shows the content is unchanged. Each later hand-off is logged with its holder, time and reason. Without those hand-off records, even unchanged files cannot be shown to be unchanged: any undocumented copying or analysis gives the other side room to argue alteration, and controls that protect or preserve the data afterwards cannot close that gap, because they say nothing about who handled it.

Analysts should work on verified working copies while the originals are preserved. When integrity is challenged, answer with something the challenger can check for themselves: recompute the hashes of the preserved originals, compare them with the values recorded at acquisition, and point to the custody entries for each working copy. Statements about the people or tools involved are assertions, and confidentiality controls say nothing about whether a key holder changed the content.

When the provider must collect the evidence

In SaaS, and often in PaaS, the customer cannot reach the systems that hold the evidence, such as the provider's internal access logs for the tenant. The chain then has to start with the provider's steps: the provider documents who collected the data, how and when, and supplies hash values computed at collection, so the customer can verify integrity on receipt and continue an unbroken chain. Anything less leaves the collection step itself undocumented, which is the first gap an opposing expert will probe. Because cooperation cannot be negotiated mid-incident, the right to provider-assisted, documented evidence collection belongs in the contract in advance. Forensic collection methodology is covered in sub-domain 5.4.