---
id: SOV08
pillar: sovereignty
title: SOV 8. How do you map your controls to the frameworks you are assessed against?
description: A provider certification covers the provider's own layer. The gap between what it covers and what you are assessed on is where most findings are located.
status: draft
services: [cspm]
tiers: [1, 2, 3]
sidebar:
order: 17
label: Compliance mapping
source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/sov-08-compliance-mapping/"
source_file: "docs/architecture/pillars/sovereignty/sov-08-compliance-mapping.mdx"
---
Compliance frameworks and architecture use different vocabularies for the same things, and the
translation between them is work that somebody has to do. Where it is left until an assessment, it
is done under pressure by whoever is available, and the result is a document that does not match
the system.
The failure that dominates is more specific than a missing control. It is the assumption that a
provider's certification covers the customer's obligations, which it does not and was never
intended to.
## Best practices
- [`SOV 8.1`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-81-identify-which-frameworks-actually-apply) Identify which frameworks actually apply
- [`SOV 8.2`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-82-map-architecture-to-control-requirements-explicitly) Map architecture to control requirements explicitly
- [`SOV 8.3`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-83-establish-the-responsibility-split-per-control) Establish the responsibility split per control
- [`SOV 8.4`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-84-keep-the-mapping-current) Keep the mapping current
---
## SOV 8.1 Identify which frameworks actually apply
**Risk if not established:** Medium
Organizations accumulate framework obligations from several directions and rarely have one list.
Regulatory frameworks apply by sector and geography. Certifications are chosen for market access.
Customer contracts import requirements. Internal standards add more.
Determine which ones genuinely bind this workload rather than which ones the organization holds. A
certification the company maintains for a different business line may not apply here, and treating
it as though it does adds controls without a reason.
Establish scope precisely for each. A framework applies to defined systems and data, and a
workload inside that scope is assessed while one outside it is not. Scope creep in either
direction is expensive: unnecessary controls in one case, an unassessed system in the other.
This is a legal and compliance determination rather than an engineering one, and the
architecture's job is to ask for the list rather than to compile it.
**On STACKIT.** The platform's own certifications are the starting point for what the provider
layer covers. STACKIT publishes its
certificates and a per-service
breakdown in the service certificates overview.
The per-service view is the one that matters for design, because **certification scope differs by
service**. A workload assembled from services with different scopes has the coverage of the
narrowest one for any control that depends on it, and checking that before the design is fixed is
considerably cheaper than during an assessment.
A sovereignty obligation may map to ES³ as well as to a
certification. Its Sovereignty Maturity Level is an audited result about a service, expressed as
one of four levels and reached only when every control mandatory for that level is met, so it
answers something a certificate does not: not whether a control exists, but how far the service has
got. Where a contract or a regulator asks for evidence of sovereignty rather than of security, that
is a useful artefact to ask a provider for and to expect to be asked for. It is one route to the
answer rather than the only one, and for a provider that has not been assessed the mapping is the
same work it has always been.
**Tradeoffs.** None inherently. The cost is the effort of establishing the list, which is smaller
than the cost of discovering a framework applies during an audit.
**Verify.** Which frameworks does your workload fall under, and who determined that? Are all its
services in scope for the ones that matter?
---
## SOV 8.2 Map architecture to control requirements explicitly
**Risk if not established:** Medium
A mapping is a document connecting each control requirement to the specific architectural element
that satisfies it, and the evidence that demonstrates it. Its value is that it exists before
somebody asks.
Three things go in each entry: the requirement, what satisfies it, and where the evidence comes
from. The third is what makes the mapping usable, and it is the one most often left implicit.
Record the gaps as entries rather than omitting them. A control marked as not satisfied, with a
reason and a plan, is a managed position. A control absent from the mapping is a finding waiting
to be made by somebody else.
Expect one architectural element to satisfy several controls across several frameworks. That
overlap is the argument for a single mapping covering all applicable frameworks rather than one
per framework, since the alternative is maintaining the same fact in several places and having
them diverge.
**On STACKIT.** Cloud Security Posture
Management evaluates resources against
benchmarks and reports the result, which is a continuous check on a subset of controls rather than
a complete mapping.
Where it applies, it converts a periodic manual review into a standing signal, and that is the
part of a mapping that stays current on its own. The controls it does not cover, which include
most process and application-level ones, still need the manual entry, and knowing which is which
is the useful distinction.
**Tradeoffs.** **Operational Excellence.** A mapping is a document to maintain, and one that has
drifted is worse than none because it is trusted.
**Verify.** For your most demanding framework, does a control-by-control mapping exist? How many
entries name specific evidence rather than describing an intent?
---
## SOV 8.3 Establish the responsibility split per control
**Risk if not established:** High
This is where the substantive findings are. Shared responsibility is understood in principle and
applied loosely, and the result is controls that both parties believe the other covers.
For each control, three positions are possible. The **provider** satisfies it entirely. **You**
satisfy it entirely. Or it is **shared**, meaning the provider supplies a capability and you have
to configure and operate it.
The third is the largest category and the one that produces the gap. A provider offering
encryption does not mean your data is encrypted; it means the capability exists and somebody has
to enable it. The same pattern applies to access control, logging, backup, network isolation and
nearly everything else.
Write the split per control rather than per service. The split changes with the deployment model:
more of it sits with the provider for a managed database than for a database you run on a virtual
machine, and a workload using both has both splits simultaneously.
Note where a [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/) or [`SOV 5`](/architecture/pillars/sovereignty/sov-05-operator-access/) decision has moved the line. Holding your own keys or running your
own component shifts controls from the provider column to yours, which is the intended effect and
which means the mapping has to be updated to match.
**On STACKIT.** The service certificates
overview establishes what is certified at the platform layer, which is the provider column.
Everything about how you configure and operate the service is yours, and no certification covers
it.
The most common misreading is treating a platform certification as covering the workload. It
covers the platform. A misconfigured deployment on a fully certified platform fails an assessment,
and the assessment is right to fail it.
**Tradeoffs.** None. Being explicit costs a column in a document and prevents the most expensive
category of finding.
**Verify.** Take five controls from your framework. For each, who satisfies it, and would the
provider agree with your answer?
---
## SOV 8.4 Keep the mapping current
**Risk if not established:** Medium
Both sides of the mapping move. The architecture changes with every release, and frameworks are
revised on their own schedule.
Attach the architecture side to change rather than to review. A change that adds a component or
moves a boundary changes the mapping, and the moment to update it is the design review under `OPS
5` rather than eleven months later.
Attach the framework side to a cadence, since revisions arrive without notice to you and a new
version can add requirements the current architecture does not meet.
The drift that matters most is silent: a control that was satisfied by a component which has since
been replaced, where the mapping still names the old one. The document reads as complete and the
control is not in place.
Sample rather than re-verifying everything. Checking a handful of entries against reality on a
cadence detects drift far more cheaply than a full re-mapping, and finding one stale entry is a
reason to look at the rest.
**On STACKIT.** CSPM benchmarks provide the
continuous half of this for the controls it evaluates, which means drift in those is detected
rather than sampled for. That is the strongest argument for expressing a control in a form the
tooling can evaluate where the option exists.
**Tradeoffs.** **Operational Excellence.** Continuing maintenance for a document whose value
appears during an assessment, which makes it easy to defer and expensive to have deferred.
**Verify.** When was your control mapping last updated, and how many releases have shipped since?
Pick three entries at random: are they still accurate?
---
## Related
- [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/) Auditability, which supplies the evidence this mapping references
- [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) Jurisdictional chain, an input to several framework requirements
- [`SEC 1.1`](/architecture/pillars/security/sec-01-security-baseline/#sec-11-derive-the-baseline-from-the-frameworks-you-are-actually-assessed-against) Baseline, which derives controls from the same frameworks
- [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/) and [`SOV 5`](/architecture/pillars/sovereignty/sov-05-operator-access/), whose decisions move the responsibility line
- [`OPS 5`](/architecture/pillars/operational-excellence/ops-05-safe-deployment/) Safe deployment, the change path where the mapping should be updated