Policy and Security as Code in Detail · Architecture as Code: the course

All courses / Architecture as Code / Module 3 / Chapter 10

Learning objectives

After the lesson the participant can:

Describe the four phases in the evolution of security management and the limitation of each.
Explain the three architectural patterns for enterprise policy management with Open Policy Agent.
Distinguish the four OSCAL models and what each contributes to audit evidence.
Sequence a Policy as Code programme using the chapter's five-step roadmap.

Key concepts

Policy as Code: Governance requirements expressed as version-controlled code, giving traceability, repeatability, peer review, automated testing and rapid rollback. It removes the delay of manual approvals and paper-heavy audits.
Open Policy Agent and Rego: A widely adopted policy engine with a declarative language built for rules over structured data. Decisions are evaluated locally, so the same rules run in unit tests and enforce guardrails in Kubernetes, Terraform pipelines or API gateways.
Decoupled evaluation, flexible distribution, bundle packaging: Three enterprise patterns: the engine runs as sidecar, admission controller or CLI verifier separate from applications; agents pull signed bundles or receive pushed updates; policies, data, metadata and signatures are packaged together for atomic roll-outs and rollbacks.
OSCAL: The Open Security Controls Assessment Language, developed by NIST, which describes controls, evidence and assessment data in machine-readable formats. It acts as the translation layer between Terraform states, pipeline runs and external auditors.
System Security Plan: The OSCAL model that assembles controls, components and operational context into a single auditable document connecting requirements to implementation. The chapter shows it generated automatically from Terraform and component definitions.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Sort

Enforce or describe: OPA and OSCAL

Sort each statement by whether the chapter says it of Open Policy Agent or of OSCAL.

Interactive exercise 2 · Put in order

Four phases of security automation

Put the four phases of security management within Architecture as Code in chronological order.

Teaching plan

15 min	Teacher presents the four phases from manual validation to holistic governance frameworks. Participants place their own organisation in a phase and say why.
15 min	Teacher explains Open Policy Agent, the three architectural patterns and the structure of a policy module covering encryption, segmentation and residency.
10 min	Walk through the OSCAL table: catalogues, profiles, component definitions and System Security Plans, with the financial institution example.
30 min	Exercise in groups: a policy inventory and pilot plan following the roadmap.
5 min	Close on the first key takeaway: governance as a continuous safety net that keeps pace with daily releases.

Discussion

Scripted automation improved speed but brought duplication and brittle scripts. What does a dedicated policy engine change about ownership of the rules?
Why does a programme need a language for describing controls and evidence in addition to an engine that enforces policies?
The roadmap begins with an inventory of manual controls. Which of yours would you automate first, and what would you measure in the pilot?

Written exercise

Exercise · 30 minutes

Policy inventory and pilot plan

Follow the first three steps of the chapter's roadmap for your own organisation. Step one: list eight existing manual controls, mark overlaps and rank them by risk, for example public exposure of administrative ports. Step two: choose two controls for a pilot in a non-production pipeline. Write each as a rule in plain structured language: the input it inspects, the condition that is a violation, the message it returns and a control identifier. Say which metric of prevented misconfigurations you will capture. Step three: for each pilot rule, name the catalogue entry or framework requirement it maps to and what a profile for your organisation would need to add.

Deliverable: A ranked inventory of eight controls, two pilot rules in structured form with identifiers and a pilot metric, and a mapping of each rule to a catalogue entry.

Your work

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

Which OSCAL model tailors catalogues to an organisation's specific needs by selecting, modifying or adding control language?
Show the answer
D. Profiles
Profiles tailor catalogues to organisation-specific needs and help harmonise overlapping regulations, as in the financial institution example that overlays GDPR Article 32 on imported controls.
What limitation does the chapter assign to Phase 2, scripted automation?
Show the answer
B. Duplication, drift and brittle scripts that were hard to share
Scripted automation in Python, Bash and PowerShell improved speed but brought duplication, drift, brittle scripts and difficult enterprise sharing.
What is the first step of the chapter's implementation roadmap?
Show the answer
A. Policy inventory of existing manual controls
The roadmap starts with a policy inventory: catalogue existing manual controls, identify overlaps and prioritise high-risk scenarios. Pilot automation follows, in a non-production pipeline.