Compliance as Code: Policy as Code for Cloud-Native SMEs

Main article: Compliance Tool Stack 2026 — which tools SMEs use for GDPR, NIS2, the EU AI Act, HinSchG and AGG, and which obligation each of them covers.

1. What is compliance as code?

Compliance as code means documenting requirements from data protection, security and compliance as code and enforcing them automatically — versioned and tested like software.

What is legally interesting about this is not the tool but the evidence. Under § 30(1) of the German BSI Act (BSIG), particularly important entities and important entities must take appropriate, proportionate and effective technical and organisational measures; compliance must be documented (§ 30(1) sentence 3 BSIG). In data protection, the accountability obligation under Art. 5(2) GDPR applies. A versioned rule base generates part of this trail automatically: who changed which requirement when, and which check ran alongside it. All references to the Austrian Network and Information Systems Security Act 2026 (NISG 2026) in this article take effect when it begins to apply on 1 October 2026.

Versioned means the following in practice: every rule exists as a text file in the repository — as a YAML or Rego file —, every change goes through the same approval as application code, and the history records author, time and reason. The file itself contains the details that the rule profile in sections 3 to 5 also lists — object checked, target state, effect in the event of a violation, and legal reference — supplemented by an identifier for the rule and a field for the reason. That is the part of the trail that arises without additional recording.

Schematically — tool-neutral and without the syntax of any particular policy language — the file therefore carries these fields, here for the example rule from section 3:

Rule:          object-storage-encryption
Object:        object storage bucket
Target state:  encryption active; storage in an EU region
Effect:        blocking
Reason:        cryptography and encryption are part of the minimum catalogue
Reference:     encryption: § 30(2) BSIG, § 32(4) NISG 2026
               EU region: practice recommendation, no legal reference

2. Tools 2026

Short answer: five tools are available — Open Policy Agent, Terraform Sentinel, AWS Config Rules, Azure Policy and Conftest. Which tool fits is decided by the existing stack; how strongly a rule takes effect is decided by where it is applied.

Practice recommendation (no legal obligation): more important than the choice of product is where a rule takes effect. A check in the pull request prevents the deviation from arising at all and leaves its result permanently attached to the change; a check in live operation only detects it afterwards and produces a dated deviation report. Both results are suitable in practice as material for documentation; the obligation itself attaches to the measures under § 30(1) and (2) BSIG, not to a product (§ 30(1) sentence 3 BSIG). Which point of application suits a specific rule is stated in the rule profile in sections 3 to 5.

For the effect of a rule, the following has proven useful: make blocking what is clearly named in the statutory minimum catalogue and is technically unambiguous to check — for example encryption, access control and multi-factor authentication (full catalogue in section 3). Make merely warning what requires a balancing exercise. Every blocking rule needs a documented exception route including responsibility, otherwise in an emergency it will be circumvented rather than applied. It has proven useful to limit every exception to 30 days: an extension requires renewed approval from the same role, otherwise the rule automatically applies again once the period expires.

3. Rule example cloud storage: enforcing encryption and storage location

A typical OPA rule reads: all S3 buckets must be encrypted and located in an EU region. In the pull request the test runs automatically; at deployment the rule blocks the deviation.

Encryption here is not an in-house rule but part of the statutory minimum catalogue of risk management measures. § 30(2) nos. 1 to 10 BSIG (Germany), § 32(4)(a) to (j) NISG 2026 (Austria) and Art. 21(2) of Directive (EU) 2022/2555 require at least the following ten areas:

For personal data, Art. 32 GDPR requires technical and organisational measures that ensure availability, integrity and confidentiality.

The second half of the example rule — storage in an EU region — is a practice recommendation and not an obligation named in the minimum catalogue. Before you fix a rule to particular regions, clarify the requirements for transfers to third countries separately — the rule only enforces the decision, it does not replace it.

In the event of damage the difference becomes tangible: under Art. 34(3) GDPR, notification of the data subjects is not required, among other things, where appropriate technical and organisational protection measures — in particular encryption — have been applied. A rule that blocks unencrypted storage therefore has an effect on a legal consequence. The notification to the supervisory authority under Art. 33(1) GDPR (without undue delay and, where feasible, within 72 hours) remains unaffected; it is dispensed with only where the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

4. Rule example access: MFA, bastion host and approval workflow

A second rule limits production access: it is possible only via multi-factor authentication, a bastion host and an approval workflow, and the rule enforces this automatically.

Practice: as the target state of this rule, bastion host means a single hardened access point — all other access routes into the production environment remain closed at network level. From this follows a criterion that is easy to check: outside this point there is no direct access to the production environment. The evidence is carried by the approval workflow, because it produces a dated, person-specific decision. Keeping the three types of log named in the profile separately has proven useful: they answer three different questions — who used elevated rights, what was changed in the configuration, and who attempted unsuccessfully to log in. The full statutory minimum catalogue is in section 3.

5. Rule example data protection: what a PII finding in the repository triggers

A pre-commit hook checks the code for personal data (PII, personally identifiable information) before it is accepted and blocks the commit if something is found.

A scanner finds patterns, not a legal basis. Whether processing is permissible is decided by Art. 6(1) GDPR: it is lawful only if at least one of the six grounds is met — consent, contract, legal obligation, vital interests, public interest or legitimate interest. For special categories, for example health data or biometric data for unique identification, Art. 9(1) GDPR imposes a general prohibition on processing with narrow exceptions under paragraph 2. A finding in the repository is therefore a reason to examine, not a verdict.

Practice recommendation (no legal obligation) for the triage after a finding, in three steps: first, name the purpose of processing and the legal basis under Art. 6(1) GDPR. Second, check whether a special category under Art. 9(1) GDPR is affected — in which case the prohibition on processing applies, and the assessment of exceptions under Art. 9(2) GDPR must be documented. Third, where a high risk is likely — in particular where new technologies are used — initiate the data protection impact assessment under Art. 35(1) GDPR before the processing begins.

Two points can be supported well technically: where processing is based on consent, the controller must be able to demonstrate that consent was given (Art. 7(1) GDPR), and withdrawal must be as easy as giving consent (Art. 7(3) GDPR). Integrating the data protection impact assessment into code reviews builds on Art. 35 GDPR. Art. 35(3) GDPR names as further triggers for the assessment referred to in step 3 the systematic and extensive evaluation of personal aspects producing legal effects (profiling), large-scale processing of special categories of data under Art. 9 GDPR, and systematic monitoring of publicly accessible areas on a large scale. If one of these points applies in the review, that is the occasion to start the assessment.

Practice, how this becomes a process step: the preliminary check belongs in the pull request template as a fixed item — the three triggers of Art. 35(3) GDPR as tick boxes. It is set up by the development role and decided by the data protection officer, otherwise by the designated data protection role. The result is a dated note on the pull request, either 'no data protection impact assessment required' with reasons or 'assessment initiated'; this note is at the same time material for accountability under Art. 5(2) GDPR.

6. SME maturity — and why it does not change the set of obligations

The maturity of the toolbox does not determine whether obligations exist — it only influences how much effort the evidence takes. Three levels are common; the allocation is a practice recommendation (no legal obligation):

• Level 1 — a single cloud provider: that provider's rule mechanics (section 2: AWS Config Rules for AWS, Azure Policy for Azure). As long as infrastructure is changed via the console, the evidence arises only afterwards, as a dated deviation report. You move to level 2 as soon as infrastructure is no longer changed in the console but as code.
• Level 2 — infrastructure is managed as code: OPA and Terraform Sentinel, supplemented by Conftest as a test step in the pipeline. Now the evidence arises as a check result at the pull request, that is, before the deviation takes effect. You move to level 3 as soon as more than one account or provider must meet the same requirement.
• Level 3 — rules are to apply across several accounts or providers: your own policies and drift detection that reports deviations from the target state in live operation. This level is reached when a requirement is defined centrally once and checked in every account; the evidence for this appears with a date in the check log.

Decisive for the set of obligations in Germany is § 28 BSIG: an entity counts as a particularly important entity if it is another entity of a type specified in Annex 1 and employs at least 250 employees or has an annual turnover of more than EUR 50 million and also an annual balance sheet total of more than EUR 43 million. An entity counts as an important entity if it is an entity of a type specified in Annex 1 or 2 with at least 50 employees or an annual turnover and an annual balance sheet total each of more than EUR 10 million, unless it already counts as a particularly important entity. Without allocation to a type in the annexes, this size classification does not apply; irrespective of these size criteria, § 28 BSIG covers, among others, qualified trust service providers, top-level domain name registries and DNS service providers. Operators of critical installations count separately as particularly important entities under § 28(1) BSIG.

In Austria, classification runs via §§ 24 and 25 NISG 2026 with the same size criteria: large enterprise from 250 employees or more than EUR 50 million turnover and more than EUR 43 million balance sheet total, medium-sized enterprise from 50 employees or more than EUR 10 million turnover and more than EUR 10 million balance sheet total.

7. Which obligations can be expressed as a rule — and which cannot

Short answer: what can be automated is the state, not the judgement. Rules check whether a measure works technically and produce the evidence for it; whether an obligation is met, whether an incident is 'significant' and whether a report is due are decided by people.

Every legal reference in the table is marked with the legal area (DE, AT or EU). The two right-hand columns are practical assessment; the references named there merely identify the relevant provision.

The reporting stages of the row 'Reporting significant security incidents' in detail (DE: § 32(1) nos. 1 to 4 BSIG, AT: § 34(2) nos. 1 to 5 NISG 2026):

• Stage 1 — without undue delay, at the latest within 24 hours of becoming aware of the incident: early initial report, in Austria an early warning.
• Stage 2 — without undue delay, at the latest within 72 hours: report with an initial assessment; Art. 23(4)(b) of Directive (EU) 2022/2555 names for this the severity, the impact and, where applicable, indicators of compromise.
• On request: an intermediate report.
• Stage 3 — at the latest one month after the 72-hour report: final report. If the incident is still ongoing, a progress report must first be submitted; the final report follows once handling has been concluded.

The recipient in Germany is the joint reporting office of the Federal Office for Information Security (BSI) and the Federal Office of Civil Protection and Disaster Assistance (BBK), and in Austria the competent — sector-specific or national — CSIRT.

On the row 'Registration with the authority' in detail: in Austria the three-month period additionally runs from the entry into force of the NISG 2026. Changes to the master data must in Germany in principle be reported without undue delay, at the latest within two weeks (§ 33(5) BSIG), and in Austria within two weeks for the core data under § 29(2) nos. 1 to 5 NISG 2026. For entities that have counted in Germany as particularly important entities or important entities since the BSIG entered into force on 6 December 2025, the three-month period under § 33(1) BSIG has expired; the BSI points out that the statutory registration deadline has already passed (section 10).

8. Audit trail: what the evidence must carry

Short answer: without an audit trail, a passed CI check remains transient console output — only logging turns it into evidence.

Minimum fields per entry: time stamp (UTC), user ID, action (read/write/delete), affected record as a hash, result (success/fail), IP address. Reproducibility here means: the same rule version produces the same check result against the same state — which is why a check log remains comprehensible even months later. These details are practice, not statutory mandatory fields. Conversely: with user ID and IP address the log itself processes personal data — treat it therefore like any other processing of personal data, including inclusion in the record of processing activities, in so far as you are required to keep one.

For tamper resistance, hash-based logs (HMAC), append-only storage and WORM storage have proven useful; immutable logs have the higher evidential value, and hash chains and time stamping increase it further. In graded terms: the minimum is append-only storage, so that entries cannot be changed after the fact. The next level is hash chaining, where the logs are to hold up against third parties. WORM storage and time stamping are worth the effort as soon as evidence is due — in Germany under § 39(1) BSIG only for operators of critical installations, in Austria under § 33 NISG 2026 for all essential entities and important entities; the cycles for this are set out in the next paragraph.

Retention: neither Directive (EU) 2022/2555 nor the BSIG nor the NISG 2026 prescribes log retention periods — 90 days operational plus 12 months archive is a practice value. Because the log contains personal data, document these values as a deletion period, not merely as a retention time. What is legally required is the documentation of compliance (§ 30(1) sentence 3 BSIG). A fixed cycle exists in Germany only for operators of critical installations: evidence by means of security audits, reviews or certifications at the earliest three years after the initial classification and thereafter every three years (§ 39(1) BSIG). In Austria, § 33 NISG 2026 applies instead: a structured self-declaration within twelve months of the registration obligation arising and — on request — evidence from an independent body within two years; essential entities must demonstrate the operational and organisational implementation within two months of being requested to do so. In Germany, commercial and tax law periods remain unaffected: depending on the type of document, six years under § 257 of the German Commercial Code (HGB) or ten years under § 147 of the German Fiscal Code (AO).

9. In what order SMEs should start

Short answer: the first step is not a rule but clarifying whether you fall within scope — without that it is unclear which obligations are to be expressed at all. The following order is a practice recommendation (no legal obligation); the references named identify the respective obligation, not the route to meeting it.

1. Clarify whether you fall within scope — management. Check whether the entity can be allocated to a type under Annex 1 or 2 and meets the size criteria: § 28 BSIG in Germany, §§ 24 and 25 NISG 2026 in Austria.
2. Check registration and catch up if necessary — management. Check whether registration took place and make good any omission without undue delay: § 33(1) BSIG via the registration facility set up jointly by the BSI and the BBK, § 29 NISG 2026 with the Cybersecurity Authority (Cybersicherheitsbehörde, Austria). Deadlines for changes to the master data are in section 7.
3. Set the first rule where the minimum catalogue applies technically — IT operations. Cryptography, access control and multi-factor authentication under § 30(2) BSIG or § 32(4) NISG 2026 can be formulated as a target state and checked automatically.
4. Log check results — IT operations, and where personal data is involved together with the data protection officer. The logs are material for the documentation of compliance under § 30(1) sentence 3 BSIG and for accountability under Art. 5(2) GDPR.
5. Define the reporting route and the classification decision as a human process — management. Record who decides whether an incident is significant (§ 2 no. 11 BSIG, § 35(1) NISG 2026) and who submits the report under § 32 BSIG or § 34 NISG 2026 — determined before the first incident occurs.

10. Limits: what policy as code does not take away

Short answer: responsibility. In Germany, the management bodies of particularly important entities and important entities must implement the risk management measures under § 30 BSIG and monitor their implementation (§ 38(1) BSIG); if they breach these duties, they are liable to their entity for culpably caused damage under the rules of the company law applicable to the legal form (§ 38(2) BSIG), and they must attend training regularly (§ 38(3) BSIG). In Austria, the management bodies must ensure and supervise compliance with the measures under § 32 NISG 2026 and attend cybersecurity training (§ 31 NISG 2026); the NISG 2026 contains no express internal liability provision such as § 38(2) BSIG — liability there follows from general company law.

Second, no pipeline handles a registration with an authority. Registration with the BSI must be carried out under § 33(1) BSIG at the latest three months after the entity acquires that status; the BSI points out that the statutory registration deadline has already passed. There is no official date for the start of supervisory and fining practice. Anyone who has missed registration should make it good without undue delay — it is a precondition for the further steps. For entities that only later count for the first time as particularly important entities or important entities, the three-month period under § 33(1) BSIG runs. And third, the balancing exercise remains: § 30(1) BSIG requires appropriate, proportionate and effective measures. What is proportionate in a specific operation cannot be stored as a rule — it must be reasoned and documented.