--- id: SEC01 pillar: security title: SEC 1. How do you establish a security baseline and detect drift from it? description: An environment is secure at a moment, in its configuration, against known techniques. All three change, so posture has to be measured rather than assumed. status: draft services: [cspm] sidebar: order: 10 label: Security baseline source_url: "https://framework.stackit.cloud/architecture/pillars/security/sec-01-security-baseline/" source_file: "docs/architecture/pillars/security/sec-01-security-baseline.mdx" --- A penetration test is a sample. It tells you about one environment on one day, and the environment changes the following week: someone opens a port for debugging, a bucket is made public for a migration, a permission is granted for an incident and never removed. None of that involves anyone doing anything wrong. It is the normal entropy of a system under development, and the only defence is a stated baseline that something measures continuously. ## Best practices - [`SEC 1.1`](/architecture/pillars/security/sec-01-security-baseline/#sec-11-derive-the-baseline-from-the-frameworks-you-are-actually-assessed-against) Derive the baseline from the frameworks you are actually assessed against - [`SEC 1.2`](/architecture/pillars/security/sec-01-security-baseline/#sec-12-measure-continuously-and-automatically-rather-than-by-periodic-audit) Measure continuously and automatically rather than by periodic audit - [`SEC 1.3`](/architecture/pillars/security/sec-01-security-baseline/#sec-13-treat-a-regression-as-an-incident-rather-than-a-backlog-item) Treat a regression as an incident rather than a backlog item - [`SEC 1.4`](/architecture/pillars/security/sec-01-security-baseline/#sec-14-cover-the-whole-estate-including-the-parts-nobody-claims) Cover the whole estate, including the parts nobody claims --- ## SEC 1.1 Derive the baseline from the frameworks you are actually assessed against **Risk if not established:** Medium A baseline assembled from general good practice produces a long list where everything is equally important, which means nothing is. A baseline derived from the obligations you actually carry has a defensible order. Start from the frameworks that apply to you, which [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) establishes: GDPR, BSI C5, ISO 27001, sector regulation, and any customer contract that imposes controls. Those give you the mandatory part. Add what your own threat model requires beyond them, since compliance frameworks are a floor rather than a ceiling. Write the baseline as checkable configuration statements rather than as principles. "Object storage buckets are not publicly readable" can be measured. "Data is appropriately protected" cannot, and a baseline made of the second kind produces audits rather than automation. Distinguish what blocks from what is reported. A control that prevents a deployment needs to be worth blocking for, and a long list of blocking controls of mixed importance trains people to look for exceptions to all of them. **On STACKIT.** CSPM checks your environment against selectable benchmarks, and the two named in the documentation are useful starting points: **BSI C5 Basic** and an internal **STACKIT Standard**. Starting from a published benchmark rather than a blank list saves the part of this work that is easiest to get wrong. > From the STACKIT docs: [Concepts › Key features](https://docs.stackit.cloud/products/security/cspm/basics/concepts/#key-features) (Source updated 08.09.2026, copied 05.10.2026) - **Project-Level Security Dashboard**: The service currently provides a single, unified view of security risks and compliance status at the project level via the STACKIT Portal UI. Future iterations will expand this to include hierarchical views at the folder and organization levels. - **Compliance Assessment**: Continuous compliance assessment against both public industry standards (like BSI C5 and ISO 27000) and the internal STACKIT Standard. - **Automated Detection & Mitigation**: Automated detection of misconfigurations and vulnerabilities, complete with guided mitigation recommendations directly in the interface. - **Compliance Report Export**: Generate and export point-in-time compliance snapshots directly from the UI. This allows you to generate tamper-evident compliance state logs to easily share your security posture and audit readiness with stakeholders. Active monitoring or alerting functionalities based on policy violations are not currently available. That maps directly onto [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/): if BSI C5 is one of the frameworks you are assessed against, the same benchmark serves your security baseline and your compliance evidence. The benchmark is a starting point rather than the whole baseline. Controls specific to your workload, your data classification and your contractual obligations sit on top of it and are yours to define. **Tradeoffs.** None between pillars. The cost is time to agree, mostly with people outside engineering. A baseline nobody has agreed is a document rather than a standard. **Verify.** Where is your security baseline written, which frameworks was it derived from, and how many of its statements are checkable by a machine? --- ## SEC 1.2 Measure continuously and automatically rather than by periodic audit **Risk if not established:** High An annual audit tells you about one day and leaves the other 364 unexamined. Configuration drifts continuously, so the measurement has to be continuous too. Two measurement points, and both are needed. **Before deployment**, in the pipeline, where a non-compliant change can be stopped before it exists. That is [`OPS 2.2`](/architecture/pillars/operational-excellence/ops-02-development-standards/#ops-22-enforce-in-the-pipeline-rather-than-in-review-comments) applied to security controls. **After deployment**, against the running environment, which catches everything that did not arrive through the pipeline: console changes, drift, and resources created by automation nobody reviewed. The second is the one teams skip, and it is the one that finds the interesting problems. A pipeline check only sees what the pipeline deploys. Make the result visible as a trend rather than as a snapshot. A count of violations that is falling tells you the practice works; a count that is stable at a low number and occasionally spikes tells you something different. Both are more useful than a pass or fail. **On STACKIT.** CSPM provides the post-deployment half: a compliance dashboard with overall health and trend data, a list of the most frequently violated policies with occurrence counts, and per-policy detail showing affected assets, severity and violation timestamps. Findings can be exported as CSV, which is what makes them usable in a report or a ticket queue. Each violation comes with a mitigation guide describing how to fix the resource. CSPM provides guidance rather than automated remediation, so the fix is a human or a pipeline action. That is the usual division for posture management tools, and it means the remediation path is something you build once rather than something that arrives configured. The pre-deployment half is yours: policy checks in STACKIT Pipelines against the infrastructure definitions from [`OPS 3`](/architecture/pillars/operational-excellence/ops-03-everything-as-code/). **Tradeoffs.** **Operational Excellence.** Continuous measurement produces findings continuously, and a stream nobody triages is worse than a periodic report somebody reads. [`SEC 1.3`](/architecture/pillars/security/sec-01-security-baseline/#sec-13-treat-a-regression-as-an-incident-rather-than-a-backlog-item) is what makes the stream actionable. **Verify.** How would you know if a storage bucket became publicly readable this afternoon? How long would it take, and who would see it? --- ## SEC 1.3 Treat a regression as an incident rather than a backlog item **Risk if not established:** Medium A finding that goes into a backlog joins a queue ordered by something other than exposure. The value of continuous measurement is the speed of the response, and a fast detector feeding a slow process delivers the slow process. Route findings by severity rather than uniformly. A publicly exposed data store with sensitive contents is an incident and should reach someone now, using the process from [`OPS 9.1`](/architecture/pillars/operational-excellence/ops-09-incident-management/#ops-91-define-severity-roles-and-escalation-before-you-need-them). A missing tag is a backlog item. Most tools produce both and give them the same shape, so the routing is yours to define. Set a maximum exposure window per severity, in the same way [`SEC 8.2`](/architecture/pillars/security/sec-08-hardening-and-patching/#sec-82-define-a-patch-cadence-with-a-maximum-exposure-window-per-severity) does for patching, and treat exceeding it as a failure of the process rather than of the individual finding. Track the exceptions. Some findings are false positives and some are accepted risks, and both need recording with a reason and an owner under [`REL 3.4`](/architecture/pillars/reliability/rel-03-failure-mode-analysis/#rel-34-record-accepted-risks-explicitly-with-who-accepted-them). What must not happen is a finding that is neither fixed nor accepted, which is the state most estates settle into. **On STACKIT.** CSPM assigns severity to findings, which is the input to the routing. Connecting that to an alert or a ticket is yours to build, since CSPM presents findings rather than dispatching them. The audit log is what tells you how a violation appeared: recorded by default for users, service accounts and the platform, at organization, folder and project scope. That answers whether a public bucket was a mistake, a deliberate change, or something that arrived through automation. **Tradeoffs.** **Operational Excellence.** Treating security findings as incidents consumes on-call capacity, and a threshold set too low produces fatigue rather than speed. **Verify.** For the last high-severity finding in your environment, how long between detection and resolution? What was the target, and where is it written? --- ## SEC 1.4 Cover the whole estate, including the parts nobody claims **Risk if not established:** High Baselines get applied to the environments people think about. The exposure is usually in the ones they do not: an old project from a proof of concept, a test environment that outlived its project, resources created by someone who has since left. These are attractive to an attacker precisely because they are unattended. They are rarely patched, rarely monitored, and frequently hold a copy of production data from whenever they were created. The fix is inventory before assessment. Enumerate what exists rather than assessing what you remember, which means the measurement runs across the whole organization rather than per project by request. Unowned resources found this way are the same list [`OPS 1.3`](/architecture/pillars/operational-excellence/ops-01-shared-ownership/#ops-13-define-ownership-so-that-every-component-has-a-name-against-it) and [`SUS 6`](/architecture/pillars/sustainability/sus-06-shut-down-idle/) produce. Assigning an owner or deleting them serves security, cost and sustainability at once, which is unusual enough to be worth doing on that basis alone. **On STACKIT.** The Resource Manager hierarchy is the enumeration: organization, folders and projects give you the full set rather than the set someone remembered to list. That is another reason the hierarchy is worth defining deliberately, per [`SEC 2.2`](/architecture/pillars/security/sec-02-segmentation/#sec-22-structure-the-resource-hierarchy-so-it-can-carry-the-boundaries-you-need). CSPM assesses what exists in the scope it covers, so the scope is the thing to check rather than assume. A project outside it is a project nobody is measuring. On STACKIT it is enabled per project. There is no organization-wide switch that takes in every project at once, which means a project nobody claimed is a project nobody is assessing, and adding a project to the estate is an explicit step rather than an automatic one. Within an enabled project the assessment covers the platform's services and runs against three policy frameworks; the policies themselves are readable through the API, which is what lets you check a finding against its rule rather than take the score on trust. The practical consequence for [`SEC 1.3`](/architecture/pillars/security/sec-01-security-baseline/#sec-13-treat-a-regression-as-an-incident-rather-than-a-backlog-item) is that enabling CSPM belongs in whatever creates a project. A measurement that has to be remembered is one that will be missed on exactly the project that needed it. **Tradeoffs.** **Cost Optimization.** Assessing everything costs more than assessing what matters, and the resources nobody claims are exactly the ones nobody will fund the assessment of. **Verify.** How many projects exist in your organization, and how many are covered by your baseline measurement? What is in the difference? --- ## Related - [`SEC 2`](/architecture/pillars/security/sec-02-segmentation/) Segmentation, which the estate structure supports - [`SEC 8`](/architecture/pillars/security/sec-08-hardening-and-patching/) Hardening and patching, a large part of what a baseline states - [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) Compliance mapping, which supplies the frameworks the baseline derives from - [`OPS 3.3`](/architecture/pillars/operational-excellence/ops-03-everything-as-code/#ops-33-detect-drift-and-treat-it-as-a-defect) Drift detection, the same discipline applied to infrastructure definitions - [`OPS 9`](/architecture/pillars/operational-excellence/ops-09-incident-management/) Incident management, which high-severity findings route into