Logging & Audit complete

• 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.

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 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.

• 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.

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:

1. 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.
2. 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.
3. 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.

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.

• 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.
• AI feature audit visibility. For SaaS tools with embedded AI, the vendor's prompt and completion logging surface has been mapped: which fields are captured, how long they are retained by default, who at the vendor can access them, and the export channel available to the customer. This is documentation only at Level 2 - the logs may still sit exclusively in vendor infrastructure - but the visibility itself is the precondition for any later sovereignty step over the AI activity record.

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

1. 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.
2. 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.
3. 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.

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.

• 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.
• AI-feature audit trails under organisation custody. Prompt and completion logs from SaaS-embedded AI features (Copilot, GitHub Copilot Business, enterprise OpenAI deployments) are forwarded into the same tamper-evident custody as other audit data. The organisation can reconstruct a specific AI event end-to-end: who issued the prompt, what context was supplied, what completion was returned, and which model handled the request. This is the AI-feature analogue of provider-administrative-action visibility - the organisation does not depend on the vendor to truthfully self-report what its AI surface produced.

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:

1. 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.
2. Tamper-evident custody. Log immutability is enforced by technical control rather than by retention policy. Write-once storage, S3 Object Lock in Compliance mode, or hash-chained entries make retroactive modification either impossible or immediately detectable. The organisation can prove logs were not altered by the provider after the fact.
3. Provider-administrative-action visibility. Provider support access, break-glass actions, and provider-initiated configuration changes are captured in the organisation's own log custody. The organisation does not depend on the provider to truthfully self-report what its own staff did.
4. Forensic readiness. With tamper-evident, sovereign log storage and provider-side admin-action coverage, the organisation can conduct forensic investigations that produce legally defensible evidence. The chain of custody for log data is clear and verifiable.
5. 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.

Even at Level 3, some dependencies 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-administrative-action coverage relies on the provider faithfully emitting events to the audit stream. If the provider fails to log a support action, no SIEM can detect what was never logged. Independent telemetry at Level 4 closes this gap.
• Cryptographic integrity may rely on provider-managed timestamp services rather than independent timestamping authorities.

These residual dependencies are addressed at Level 4.

• 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.

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:

1. 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.
2. 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.
3. 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.
4. Provider termination. If the provider relationship ends - whether voluntarily or involuntarily - the organisation retains complete historical audit records with provable integrity.

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.

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.