SOV 8. How do you map your controls to the frameworks you are assessed against?
Zuletzt aktualisiert am
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
Section titled “Best practices”SOV 8.1Identify which frameworks actually applySOV 8.2Map architecture to control requirements explicitlySOV 8.3Establish the responsibility split per controlSOV 8.4Keep the mapping current
SOV 8.1 Identify which frameworks actually apply
Section titled “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
Section titled “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
Section titled “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 or SOV 5 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
Section titled “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
Section titled “Related”SOV 7Auditability, which supplies the evidence this mapping referencesSOV 6Jurisdictional chain, an input to several framework requirementsSEC 1.1Baseline, which derives controls from the same frameworksSOV 4andSOV 5, whose decisions move the responsibility lineOPS 5Safe deployment, the change path where the mapping should be updated