Logging & Audit complete

Control over audit trails, log storage, monitoring systems, and forensic capabilities

L0 Unaware

No logging strategy exists. Default provider logs may be active but are neither reviewed nor governed. There is no retention policy, no audit trail, and no forensic capability.

Criteria

AUDIT-L0-C1 The organisation has no awareness of which external parties generate, store, or have access to its operational logs.

Evidence guidance

Ask the organisation to identify where its logs are stored and who can access them. Inability to answer satisfies this criterion.
AUDIT-L0-C2 Logs exist only as provider defaults (e.g., basic cloud console activity logs) and are neither actively monitored nor forwarded to any centralised system.

Evidence guidance

Review cloud provider logging configurations and ask operations staff whether any log aggregation or review process exists.

Indicators

No one in the organisation can describe where logs are stored or what events are captured.
Security incidents are discovered by end users or customers rather than through monitoring systems.
The organisation has never performed a log-based forensic investigation.
Provider default log retention periods are unknown to IT staff.

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-5, art-30	critical	GDPR Art. 5(2) requires demonstrable accountability. Without audit trails the organisation cannot prove compliance with processing principles. Art. 30 mandates records of processing activities, which are impossible to verify without logging.
`NDSG`	art-8	high	nDSG Art. 8 requires appropriate technical measures to ensure data security. Complete absence of logging prevents detection of unauthorised access or data breaches.
`NIS2`	art-21	high	NIS2 Art. 21(2)(g) requires policies on security monitoring and logging. Total absence of a logging strategy constitutes non-compliance for in-scope entities.

Upgrade path

Define a baseline logging policy identifying critical systems and the events that must be captured. Enable provider-native logging services (CloudWatch, Azure Monitor, GCP Cloud Logging) with explicit retention periods. Assign ownership for log review to a named individual or team.

Risk if stagnant

Without any logging capability the organisation is blind to security incidents, unable to support forensic investigations, and cannot demonstrate regulatory compliance. Breach detection time extends to months or years, significantly increasing the impact of any compromise.

Typical characteristics

No logging policy. There is no document defining which events should be logged, where log data should reside, or how long it must be retained. Logging is treated as a provider implementation detail rather than a governance concern.
Invisible log lifecycle. Logs may be silently created and silently expired according to provider defaults. The organisation is unaware of the retention window and has never verified whether logs are available when needed.
No monitoring or alerting. No dashboards, alerting rules, or scheduled log reviews exist. Anomalous behaviour - failed logins, privilege escalations, data exports - goes unnoticed unless it causes a visible outage.
No forensic readiness. In the event of a security incident, the organisation cannot reconstruct a timeline of events because the necessary log data either does not exist or cannot be located.

Why this is dangerous

Logging is the foundation of accountability. Without audit trails, the organisation cannot determine who accessed what data, when, and from where. This makes it impossible to detect breaches in a timely manner, to comply with the 72-hour breach notification requirement under GDPR Art. 33, or to provide regulators with evidence of compliance.

From a sovereignty perspective, the absence of logging means the organisation cannot even assess whether a foreign jurisdiction has accessed its data. If a US-headquartered cloud provider receives a CLOUD Act order, there is no audit trail to reveal that data was disclosed.

Sovereignty implications

Sovereignty requires visibility. An organisation that cannot observe its own systems cannot govern them. At Level 0, the question of log sovereignty is moot - there is no log data over which to exercise sovereignty.

L1 Dependent

Logging is active through provider-managed services (CloudWatch, Azure Monitor, GCP Cloud Logging). The provider controls log format, storage location, retention defaults, and access mechanisms. Export options are limited or unused.

Criteria

AUDIT-L1-C1 The organisation uses provider-native logging services as its primary logging infrastructure, with log storage residing entirely within the provider's platform.

Evidence guidance

Verify that logging services such as AWS CloudWatch, Azure Monitor, or GCP Cloud Logging are enabled. Confirm that no external log aggregation or SIEM is in use.
AUDIT-L1-C2 Log format, schema, and retention periods are determined by the provider's defaults or are only configurable within provider-defined constraints.

Evidence guidance

Review log retention configurations in the provider console. Check whether custom log schemas or formats have been defined. Provider-default settings with no organisational override satisfy this criterion.
AUDIT-L1-C3 Log data cannot be exported in a timely or automated manner to an independent storage system outside the provider's platform.

Evidence guidance

Attempt to export a representative log dataset. Check whether automated export pipelines (e.g., to S3, Azure Blob, or an external SIEM) are configured. Absence of automated export satisfies this criterion.

Indicators

All logging dashboards are accessed through the cloud provider's console (e.g., CloudWatch console, Azure Portal).
Log retention is set to provider defaults (e.g., CloudWatch 14-day default) with no organisational override.
No log data exists outside the provider's platform - there is no independent backup or archive.
The organisation cannot produce logs from more than 90 days ago without provider assistance.

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-5, art-33	high	While basic logging exists, provider dependency means the organisation cannot independently verify log completeness or integrity. Breach detection relies on provider tooling, which may delay Art. 33 notification.
`NDSG`	art-8	medium	Provider-managed logging partially satisfies nDSG Art. 8 data security requirements, but lack of independent control over log data weakens the compliance posture.
`NIS2`	art-21, art-23	high	NIS2 Art. 21 requires security monitoring capabilities. Provider-dependent logging may not meet the incident reporting timelines in Art. 23 if log access is constrained by provider SLAs.
`DORA`	art-12	high	DORA Art. 12 requires ICT-related incident detection capabilities. Full dependency on a single provider's logging creates concentration risk and may hinder independent incident classification.

Upgrade path

Negotiate explicit log retention and export terms in the provider contract or DPA. Establish automated log export to a provider-independent storage layer. Define a log retention policy that meets regulatory minimums (typically 1-3 years). Begin evaluating SIEM solutions for independent log analysis.

Risk if stagnant

Complete provider dependency for logging creates a single point of failure for audit and forensic capability. If the provider relationship is terminated, log history is lost. Provider-side log access by foreign jurisdictions (e.g., CLOUD Act) cannot be detected or prevented. Incident response timelines are constrained by provider SLA rather than organisational need.

Typical characteristics

Provider-native tooling only. The organisation relies exclusively on services such as AWS CloudWatch, Azure Monitor, or GCP Cloud Logging. These services are enabled, and basic dashboards or alerts may exist, but all log data resides within the provider's platform.
Provider-controlled format and retention. Log schemas follow provider-defined formats. Retention periods are either left at defaults or configured within provider-imposed constraints (e.g., CloudWatch Logs Insights queries limited to specific time windows).
Limited export capability. While providers offer log export features (e.g., CloudWatch to S3, Azure Monitor to Storage Account), these are either not configured or are performed manually and infrequently.
No independent verification. The organisation trusts the provider's logging completeness implicitly. There is no mechanism to verify that all events are captured or that logs have not been modified.

Why this matters

Provider-managed logging is a significant step above Level 0 - the organisation can at least review events and respond to incidents using provider tooling. However, the dependency introduces several sovereignty concerns:

Jurisdictional exposure. Logs stored within a US-headquartered provider's infrastructure may be subject to CLOUD Act disclosure without the organisation's knowledge. The logs themselves - which often contain IP addresses, user identifiers, and access patterns - constitute personal data under GDPR.
Portability risk. If the organisation needs to change providers, historical log data may be difficult or impossible to migrate. Provider-specific log formats and query languages create technical lock-in.
Forensic limitations. In a dispute with the provider, the organisation cannot independently verify log integrity. The provider is both the custodian of evidence and a potential party to the investigation.

Sovereignty implications

The organisation has logging capability but no logging sovereignty. The provider can modify retention policies, change log formats, or comply with foreign government data requests - all without the organisation's knowledge or consent. True audit sovereignty requires independent control over log storage and integrity, which begins at Level 2.

L2 Contractual

Log retention and export requirements are formalised in DPAs and service contracts. Automated log export to organisation-controlled storage is operational. However, the provider still generates and initially processes all log data, retaining access to logs and metadata.

Criteria

AUDIT-L2-C1 The Data Processing Agreement (DPA) or service contract specifies minimum log retention periods, log categories to be captured, and the organisation's right to export log data.

Evidence guidance

Review the DPA and service agreements for explicit clauses on log retention, log types, and export rights. Generic clauses without specific retention periods do not satisfy this criterion.
AUDIT-L2-C2 Automated log export pipelines are operational, forwarding provider-generated logs to an organisation-controlled storage system on a near-real-time or daily basis.

Evidence guidance

Verify the existence of automated log export configurations (e.g., CloudWatch Subscription Filters, Azure Event Hub export, Pub/Sub to external storage). Check that exports are current and not stale.
AUDIT-L2-C3 A formal log retention policy defines retention periods per log category, aligned with regulatory requirements (GDPR, NIS2, DORA).

Evidence guidance

Request the log retention policy document. Confirm that retention periods meet regulatory minimums (e.g., 1 year for NIS2, up to 5 years for DORA).
AUDIT-L2-C4 The provider retains access to log data and metadata, and the organisation has not established independent log integrity verification.

Evidence guidance

Confirm that log data passes through provider infrastructure before reaching the organisation's storage. Verify that no log integrity mechanisms (e.g., hash chains, write-once storage) are in place on the organisation's copy.

Indicators

DPA includes specific clauses on log retention periods and export rights.
Automated log export pipelines are running and monitored for failures.
The organisation maintains a copy of provider logs in its own storage infrastructure.
Log retention periods are documented and aligned with regulatory requirements (minimum 1 year for NIS2, up to 5 years for DORA).

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-5, art-30, art-33	medium	Contractual log retention supports Art. 5(2) accountability and Art. 30 records of processing. Automated export improves Art. 33 breach notification capability, but provider access to logs remains a gap.
`NDSG`	art-8	medium	Formalised log management with export demonstrates appropriate technical measures under nDSG Art. 8, though provider access to log data introduces residual risk.
`NIS2`	art-21, art-23	medium	Contractual logging requirements and export capabilities support NIS2 Art. 21 monitoring obligations. Near-real-time export enables faster Art. 23 incident reporting.
`DORA`	art-12	medium	DORA Art. 12 incident detection is supported by formalised logging. Dual-location log storage (provider and organisation) reduces concentration risk.

Upgrade path

Deploy a self-managed SIEM (e.g., Wazuh, ELK/OpenSearch, Graylog) to achieve independent log analysis capability. Implement tamper-proof log storage using write-once media or cryptographic hash chains. Establish real-time alerting independent of provider tooling. Begin routing all provider logs through the organisation's SIEM as the primary analysis platform.

Risk if stagnant

While contractual protections and log export are significant improvements, the provider still generates and initially handles all log data. Provider-side log manipulation or omission - whether through error, legal compulsion, or malicious action - cannot be independently detected. The organisation's forensic capability depends on the provider's willingness and ability to generate complete logs.

Typical characteristics

Contractual log governance. The DPA or service contract explicitly defines which log categories must be captured, minimum retention periods, and the organisation's right to export and access log data. These are not generic terms but specific, enforceable obligations.
Automated export pipelines. Log data flows automatically from provider logging services to organisation-controlled storage - typically an object store or data lake in a separate account, subscription, or infrastructure. Export runs on a near-real-time or daily schedule.
Defined retention policy. A formal log retention policy exists, specifying retention periods per log category (e.g., authentication logs for 3 years, application logs for 1 year). Automated lifecycle management enforces these periods.
Dual-location storage. Logs exist in two places: the provider's native logging infrastructure and the organisation's export destination. This provides redundancy but not independence - the organisation's copy is derived from the provider's original.

Key limitations

The fundamental limitation at Level 2 is that the provider remains the authoritative source of log data. Several risks persist:

Log generation trust. The organisation trusts that the provider generates complete and accurate logs. If the provider fails to log certain events - whether through a bug, a configuration error, or a legal obligation to suppress certain records - the organisation has no independent way to detect the omission.
Metadata exposure. Even with log export, the provider retains access to log metadata: who accessed what, when, and from where. This metadata may itself be subject to foreign jurisdiction data requests.
No integrity verification. The exported log copy has no cryptographic integrity guarantee. The organisation cannot prove that its log archive has not been tampered with, which weakens its value in legal proceedings or regulatory investigations.

Sovereignty implications

Level 2 establishes contractual sovereignty over log data - the organisation has legal rights to its logs and operational mechanisms to exercise those rights. However, technical sovereignty remains incomplete. The provider can still observe, access, and potentially influence the log data before it reaches the organisation's storage. True audit sovereignty requires independent log generation and tamper-evident storage, which emerge at Level 3.

L3 Controlled

The organisation operates a self-managed SIEM (e.g., Wazuh, ELK/OpenSearch) with logs stored in a sovereign jurisdiction. Tamper-proof log storage, real-time alerting, and provider log forwarding to the organisation's SIEM are operational. Independent forensic capability is established.

Criteria

AUDIT-L3-C1 A self-managed SIEM platform is operational, serving as the primary log analysis and alerting system.

Evidence guidance

Verify the SIEM deployment (e.g., Wazuh, ELK, OpenSearch, Graylog). Confirm it is the primary platform used for log analysis and security alerting, not a secondary or unused installation.
AUDIT-L3-C2 All log storage resides within a sovereign jurisdiction, with documented data residency controls ensuring logs do not leave the designated jurisdiction.

Evidence guidance

Verify the physical location of SIEM storage infrastructure. Review data residency configurations and confirm that log replication or backup does not cross jurisdictional boundaries.

Indicators

A self-managed SIEM (Wazuh, ELK, OpenSearch, Graylog) is deployed and receives logs from all critical systems including cloud providers.
Log storage infrastructure is located within the organisation's sovereign jurisdiction with documented data residency controls.
Historical log entries cannot be modified or deleted - immutability is enforced through technical controls, not just policy.
Security alerting operates independently of cloud provider alerting services and has been tested through simulated incidents.

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-5, art-30, art-33	low	Self-managed SIEM with sovereign storage provides strong Art. 5(2) accountability. Tamper-proof logs support Art. 30 record-keeping. Real-time alerting enables Art. 33 72-hour breach notification.
`NDSG`	art-8	low	Comprehensive logging with sovereign data residency and integrity controls exceeds nDSG Art. 8 technical measure requirements.
`NIS2`	art-21, art-23	low	Self-managed SIEM with real-time alerting directly addresses NIS2 Art. 21 monitoring requirements. Independent detection capability supports Art. 23 early warning obligations (24 hours for significant incidents).
`DORA`	art-12	low	DORA Art. 12 ICT-related incident detection is fully supported through independent SIEM with tamper-proof storage. No single-provider concentration risk for logging.

Upgrade path

Deploy fully self-hosted logging infrastructure on organisation-owned hardware, eliminating any residual IaaS dependency for log storage. Implement cryptographically signed audit trails with independent timestamping authority. Establish air-gapped log archive for critical audit records. Remove all dependency on provider-generated logs by deploying independent telemetry agents.

Risk if stagnant

Level 3 provides strong audit sovereignty for most organisations. However, residual risks remain: the SIEM infrastructure may still run on IaaS (introducing a provider dependency layer beneath the logging system), and provider-generated logs are still trusted as a primary source. Organisations in highly regulated sectors or those facing nation-state threats may require the full independence of Level 4.

Typical characteristics

Self-managed SIEM. The organisation operates its own Security Information and Event Management platform - typically open-source solutions such as Wazuh, the ELK stack (Elasticsearch, Logstash, Kibana), OpenSearch, or Graylog. This SIEM is the primary interface for security monitoring and incident investigation.
Provider log forwarding. All provider-native logs (CloudWatch, Azure Monitor, GCP Cloud Logging) are forwarded to the organisation's SIEM through automated pipelines. The SIEM provides a unified view across all environments, including on-premises systems.
Sovereign log storage. Log data is stored within the organisation's sovereign jurisdiction. Data residency controls are documented and enforced, ensuring that audit records are not subject to foreign jurisdiction access without the organisation's knowledge.
Tamper-proof storage. Log immutability is enforced through technical controls: write-once storage (WORM), S3 Object Lock in Compliance mode, or cryptographic hash chains where each log entry references the hash of the previous entry. Retroactive modification of audit records is prevented or immediately detected.
Real-time alerting. Security alerting rules are defined in the organisation's SIEM, covering critical events such as authentication anomalies, privilege escalation, data exfiltration indicators, and configuration changes. These alerts operate independently of provider-native alerting.

Why this is a significant milestone

Level 3 represents the point at which the organisation can independently verify its security posture without relying on the provider's word. Key capabilities include:

Independent incident detection. The organisation can detect security events through its own SIEM, even if the provider's alerting fails or is suppressed. This is critical for incidents involving the provider itself.
Forensic readiness. With tamper-proof, sovereign log storage, the organisation can conduct forensic investigations that produce legally defensible evidence. The chain of custody for log data is clear and verifiable.
Regulatory demonstration. The organisation can demonstrate compliance with GDPR Art. 33 breach notification, NIS2 Art. 23 incident reporting, and DORA Art. 12 incident detection through its own systems, without depending on provider cooperation.

Remaining dependencies

Even at Level 3, some dependencies may persist:

The SIEM infrastructure itself may run on IaaS (e.g., Elasticsearch on EC2 instances), introducing a layer of provider dependency beneath the logging system.
Provider-generated logs are still trusted as a primary data source. If the provider omits certain events from its logs, the SIEM cannot detect what was never logged.
Cryptographic integrity may rely on provider-managed timestamp services rather than independent timestamping authorities.

These residual dependencies are addressed at Level 4.

L4 Autonomous

Fully self-hosted logging infrastructure on organisation-owned hardware. Cryptographically signed audit trails with independent timestamping. Air-gapped log archive for critical records. Complete forensic capability with no provider log dependency - all telemetry is generated by organisation-controlled agents.

Criteria

AUDIT-L4-C1 All logging infrastructure - collection, processing, storage, and analysis - runs on organisation-owned or organisation-controlled hardware with no dependency on cloud provider IaaS for the logging pipeline itself.

Evidence guidance

Verify that the SIEM, log storage, and analysis platforms run on infrastructure owned or directly leased by the organisation (co-location or on-premises). Confirm that no component of the logging pipeline depends on a cloud provider's compute, storage, or networking services.
AUDIT-L4-C2 Audit trails are cryptographically signed using organisation-controlled keys with independent timestamping from a trusted third-party timestamping authority (TSA), producing legally defensible, non-repudiable audit records.

Evidence guidance

Review the cryptographic signing mechanism for log entries. Verify that signing keys are held in an HSM or equivalent secure key store under organisational control. Confirm that timestamps are obtained from a qualified TSA (e.g., RFC 3161 compliant) independent of the cloud provider.
AUDIT-L4-C3 An air-gapped log archive exists for critical audit records, physically isolated from all networked systems, with documented procedures for secure write and read operations.

Evidence guidance

Inspect the air-gapped archive facility. Verify physical isolation (no network connectivity). Review the procedures for transferring log data to the archive and for retrieving records during investigations. Confirm that archive integrity is periodically verified.
AUDIT-L4-C4 The organisation generates its own telemetry independently of provider logging, ensuring forensic capability even if provider logs are unavailable or compromised.

Evidence guidance

Verify that the organisation operates independent telemetry collection (e.g., osquery, Beats, Fluentd, custom agents) that provides forensic coverage without relying on provider-generated log data as the sole source.

Indicators

The entire logging pipeline runs on organisation-owned infrastructure with no cloud provider dependency for any component.
Every audit record carries a cryptographic signature verifiable with organisation-controlled keys and an independent RFC 3161 timestamp.
An air-gapped archive facility exists with documented chain-of-custody procedures for critical audit records.
Organisation-deployed telemetry agents operate on all critical systems, generating logs independently of provider logging services.

Regulatory mappings

Regulation	Articles	Risk	Note
`GDPR`	art-5, art-30, art-33	minimal	Cryptographically signed, air-gapped audit trails provide the highest level of Art. 5(2) accountability. Complete forensic capability supports Art. 33 breach notification with precise, tamper-evident evidence. Art. 30 records are independently verifiable.
`NDSG`	art-8	minimal	Fully sovereign logging infrastructure with cryptographic integrity and air-gapped archival represents the highest standard of technical measures under nDSG Art. 8.
`NIS2`	art-21, art-23	minimal	Complete logging autonomy exceeds NIS2 Art. 21 monitoring requirements. Independent telemetry and air-gapped archives ensure Art. 23 incident reporting is never constrained by provider dependencies.
`DORA`	art-12	minimal	DORA Art. 12 ICT-related incident detection is fully autonomous. No concentration risk, no provider dependency. Cryptographic integrity supports regulatory evidence requirements.

Risk if stagnant

Level 4 represents the maximum maturity for logging and audit sovereignty. The primary risk is operational: maintaining fully self-hosted logging infrastructure requires significant engineering investment, and the air-gapped archive demands rigorous physical security procedures. Organisations must ensure that the operational burden does not lead to degraded maintenance or monitoring gaps over time.

Typical characteristics

Fully self-hosted infrastructure. The SIEM platform, log storage, and all supporting services (message queues, search indices, dashboards) run on organisation-owned hardware, whether on-premises or in a co-location facility under the organisation's physical control. There is no cloud provider in the logging critical path.
Cryptographically signed audit trails. Every log entry is signed using keys held in an HSM under organisational control. Timestamps are obtained from an independent, qualified Timestamping Authority (TSA) compliant with RFC 3161. This produces audit records that are non-repudiable and legally defensible - they can prove that a specific event occurred at a specific time and that the record has not been altered since.
Air-gapped archival. Critical audit records - particularly those related to security incidents, regulatory evidence, and legal proceedings - are periodically transferred to an air-gapped archive. This archive has no network connectivity and is physically secured. Data transfer uses write-once media with documented chain-of-custody procedures.
Independent telemetry. Organisation-deployed agents (osquery, Elastic Beats, Fluentd, Wazuh agents, or custom-built collectors) generate telemetry directly from endpoints, servers, network devices, and applications. The organisation does not depend on provider-generated logs as a primary data source. If a cloud provider's logging is disabled, compromised, or legally compelled to omit certain events, the organisation's independent telemetry continues to capture the relevant activity.

Why Level 4 matters

Level 4 addresses the most sophisticated threat models - those involving the cloud provider itself as a potential adversary or as a party compelled by a foreign government to act against the organisation's interests. Specific scenarios include:

Compelled disclosure with gag order. A foreign government compels the provider to disclose data and prohibits the provider from notifying the customer. At Level 4, the organisation's independent telemetry would detect anomalous data access patterns even without provider cooperation.
Provider compromise. If the provider's logging infrastructure is compromised by a nation-state actor, the organisation's independently generated and cryptographically signed logs remain trustworthy.
Legal proceedings. In litigation or regulatory investigations, cryptographically signed logs with independent timestamps constitute stronger evidence than provider-generated logs, which could be challenged on grounds of potential tampering.
Provider termination. If the provider relationship ends - whether voluntarily or involuntarily - the organisation retains complete historical audit records with provable integrity.

Operational considerations

Level 4 demands significant operational investment:

Hardware lifecycle management. The organisation is responsible for capacity planning, hardware procurement, and infrastructure maintenance for the entire logging pipeline.
Archive procedures. Air-gapped archival requires rigorous physical security, documented transfer procedures, and periodic integrity verification. These processes must be rehearsed and audited.
Key management. Cryptographic signing keys must be managed through a formal key lifecycle, including generation in HSMs, rotation schedules, and secure backup. Compromise of signing keys would undermine the integrity of the entire audit trail.
Agent deployment and maintenance. Independent telemetry agents must be deployed, configured, updated, and monitored across all systems. Agent coverage gaps create blind spots in the organisation's visibility.

Sovereignty implications

Level 4 represents complete audit sovereignty. The organisation generates, collects, processes, stores, and archives its own audit data using its own infrastructure, its own keys, and its own procedures. No external party - provider, government, or adversary - can access, modify, or suppress audit records without the organisation's knowledge. This is the foundation upon which all other sovereignty claims rest: if you cannot independently observe and prove what happened, you cannot govern your own systems.