Warmup Guide — Compliance and Authorization Engineering (FedRAMP and Beyond)

Zero-to-expert primer for Phase 15 (elite/principal track). To a paperwork shop, compliance is screenshots; to a principal security engineer, a compliance framework is a requirements specification you implement as tested controls with continuously-fresh evidence — and an authorization (FedRAMP ATO, DoD IL5, PCI AoC, SOC 2 report, ISO 27001 cert) is a precondition to having customers at all in regulated markets. This phase builds, from first principles, how authorization actually works as engineering: NIST 800-53 controls and baselines, the FedRAMP ATO process, control inheritance, OSCAL (machine-readable controls / "compliance as code"), continuous monitoring and POA&M SLAs, FIPS-validated cryptography, the authorization boundary, and how the major regimes (PCI/HIPAA/SOC 2/ISO/CMMC) compare. Assumes Phase 07. By the end you should understand how an authorization is engineered and be able to build the engines in the labs.

Table of Contents

Chapter 1: Compliance as Engineering, Not Paperwork

Zero background. A compliance framework is a list of required security controls plus a process to prove you operate them. An authorization is a formal decision by an accountable official that a system's risk is acceptable, granted because the controls are in place and evidenced. The novice sees this as bureaucracy — screenshots in a binder. The principal sees it as a requirements specification: each control is a property to implement, test, and continuously evidence, exactly like the requirement→control→test→evidence chain you built in Phase 03 and Phase 07.

Why this is a hands-on, high-leverage engineering skill. In regulated markets — US government (FedRAMP), defense (CMMC/IL), payments (PCI), health (HIPAA), enterprise SaaS (SOC 2/ISO) — an authorization is table stakes to sell at all. The difference between a company that earns FedRAMP High in 9 months and one that flails for 3 years is whether security treats it as engineering (controls as code, automated evidence, continuous monitoring) or as a last-minute documentation scramble. Done as engineering, the same controls satisfy the auditor and genuinely protect customers; the evidence chain serves both. This is how you build "services the customer can trust" — and prove it to their auditors.

Misconception to kill now. "Compliance ≠ security." Half-true: checkbox compliance isn't security. But compliance engineered properly — tested controls, fresh evidence, continuous monitoring — is a strong, externally-validated security backbone. The failure is treating it as paperwork; the win is treating it as code.

Chapter 2: NIST 800-53 — Controls, Families, and Baselines

The control catalog. NIST SP 800-53 is the master catalog of security and privacy controls, organized into ~20 families by a two-letter prefix:

AC Access Control   AU Audit & Accountability   CM Configuration Mgmt   IA Identification & Auth
SC System & Comms Protection   SI System & Info Integrity   CP Contingency Planning   IR Incident Response
RA Risk Assessment   CA Assessment & Authorization   ... (and more)

Each control has an id like AC-2 (Account Management), often with enhancements like AC-2(11) (stricter sub-requirements applied at higher assurance). A control is a requirement ("the system manages accounts: provisioning, review, disabling…"), not an implementation — how you satisfy it is your implementation statement.

Baselines select the required set. You don't implement all ~1000 controls — you implement the baseline matched to your system's impact level (FIPS 199 categorization of confidentiality/ integrity/availability impact):

  • Low — limited adverse impact; smallest control set.
  • Moderate — serious adverse impact; the most common FedRAMP baseline (≈300+ controls).
  • High — severe/catastrophic impact; the largest set, with the strictest enhancements.

The baselines nest: Moderate includes Low plus more; High includes Moderate plus more. This is exactly the BASELINE_CONTROLS model in Lab 01 — selecting moderate requires every low control plus the moderate additions, so a Low-complete system is not Moderate-ready.

Misconception to kill now. "We implement the controls that apply to us." The baseline (driven by your impact categorization) defines the required set — and at higher impact, the enhancements (the (n) sub-controls) are where most of the additional work lives.

Chapter 3: The FedRAMP Authorization (ATO) Process

What FedRAMP is. FedRAMP standardizes how US federal agencies authorize cloud services — "do once, use many." A Cloud Service Provider (CSP) achieves an authorization that agencies can reuse. The artifacts and actors:

  • SSP (System Security Plan) — the central document: the authorization boundary, the data flows, and an implementation statement for every control in the baseline (how you satisfy AC-2, etc.).
  • 3PAO (Third-Party Assessment Organization) — an accredited independent assessor that tests the controls and writes the SAR (Security Assessment Report), with findings.
  • POA&M (Plan of Action & Milestones) — the tracked list of open gaps/findings with remediation dates (Chapter 6).
  • Authorizing Official (AO) — accepts the residual risk and grants the ATO (Authorization to Operate). FedRAMP also has a P-ATO via the Joint Authorization Board / the FedRAMP PMO.

The flow (simplified): categorize impact (FIPS 199) → select baseline → implement controls → document in the SSP → 3PAO assessment → SAR + POA&M → AO risk decision → ATO → continuous monitoring (Chapter 6) forever after.

The crucial insight — you can be authorized with open gaps. An ATO does not require zero findings. It requires that every gap is tracked in an open POA&M with a remediation date, and that the AO accepts the residual risk. This is exactly the logic of Lab 01: a planned/not-implemented control is acceptable iff it links an open, on-time POA&M; a gap without a POA&M, or with an overdue one, blocks authorization. Mature security engineering is about managing risk transparently, not pretending it's zero.

Misconception to kill now. "ATO means everything is fixed." It means everything is implemented, inherited, or tracked in a POA&M with the AO's risk acceptance. An honest, tracked gap is authorizable; a hidden one is fraud.

Chapter 4: The Authorization Boundary and Control Inheritance

The boundary. The authorization boundary defines exactly what is in scope — the components, data flows, and interconnections the authorization covers. Drawing it precisely is foundational: too broad and you over-test; too narrow and you exclude something that handles the data (a finding, or worse).

Control inheritance — the highest-leverage concept. You don't re-implement everything. If you build on an already-authorized IaaS (e.g. an AWS GovCloud / Azure Government FedRAMP-High environment), you inherit the controls the provider owns (physical security, hypervisor, much of the network and media protection) — the shared-responsibility model from Phase 07, formalized. Your SSP marks those controls inherited, names the provider, and documents the boundary of inheritance; you implement the controls above the line (your IAM, your app, your data handling).

Why inheritance must be substantiated. An inheritance claim is only valid if it names the authorized provider and the inheritance is real — you can't claim to inherit a control the provider doesn't actually cover for your usage. This is exactly the inheritance-unsubstantiated check in Lab 01: an inherited control with no named provider is a finding. Mis-stated inheritance is one of the most common (and dangerous) FedRAMP errors — a control everyone assumed someone else owned.

Misconception to kill now. "We're on FedRAMP-authorized cloud, so we inherit compliance." You inherit specific controls the provider owns within the boundary of their authorization; the controls you own (your IAM, encryption config, logging, app security) are still yours to implement and evidence. Inheritance shrinks the work, it doesn't eliminate it.

Chapter 5: OSCAL and Compliance as Code

The problem OSCAL solves. Traditionally, control documentation lives in Word/Excel — un-queryable, un-testable, perpetually stale. OSCAL (Open Security Controls Assessment Language), from NIST, makes controls, baselines, SSPs, assessment plans/results, and POA&Ms machine-readable (JSON/XML/YAML). It turns compliance into data you can validate, diff, and automate.

What machine-readable controls enable — the engineering win:

  • Automated validation — a tool (like Lab 01) checks that every baseline control has an implementation/inheritance/POA&M and evidence, computing authorization readiness instantly instead of a human reading 300 narratives.
  • Inheritance as data — provider control coverage is expressed in OSCAL and imported, so your responsibility is computed, not guessed.
  • Continuous assessment — assessment results are OSCAL, so the gap between "documented" and "actually operating" closes; evidence freshness is tracked (Chapter 6).
  • Reuse — a control implementation can be shared across products; a baseline is a profile applied to the catalog.

This is "compliance as code": the same shift-left, test-it, version-it, automate-it discipline you apply to security controls (Phase 03/07), applied to the authorization artifacts themselves.

Misconception to kill now. "OSCAL is just a new document format." It's the difference between compliance that's audited once a year by hand and compliance that's continuously validated by machine — the leverage that makes High-baseline authorization tractable.

Chapter 6: Continuous Monitoring and the POA&M

The ATO is not a finish line. FedRAMP requires Continuous Monitoring (ConMon) — the authorization is conditional on ongoing operation of the controls, and the AO can revoke it when ConMon lapses. The ConMon machinery (this is Lab 02):

  • Monthly authenticated vulnerability scans of operating systems, web applications, and databases. A scan older than ~30 days is a deliverable failure (scan-stale/scan-missing).
  • POA&M remediation SLAs by severity (FedRAMP guidance): High = 30 days, Moderate = 90 days, Low = 180 days, from first detection. A finding past its SLA is overdue — a compliance failure the AO sees.
  • Deviation requests — a finding may carry an approved deviation that stops the SLA clock: a False Positive, a Risk Adjustment (the real risk is lower than the scanner's rating), or an Operational Requirement (it can't be remediated without breaking the service). An expired or absent deviation does not help — exactly the expired-deviation logic in Lab 02.
  • Vendor dependency — a finding in inherited/provider scope is tracked separately and doesn't count against your SLA (but must still be managed).

Why this is real security, not paperwork. ConMon is just vulnerability management with enforced SLAs and an external auditor — the Phase 03 vulnerability-management workflow, made non-optional. The severity SLAs force you to actually fix high-severity findings fast, which is precisely the behavior good security wants.

Misconception to kill now. "We got the ATO, compliance is done." The ATO starts the ConMon obligation. A lapse — stale scans, overdue POA&Ms — can cost you the authorization and the customers it unlocked.

Chapter 7: FIPS 140-3 — Validated Cryptography

The requirement. FedRAMP, DoD, and many regimes require that cryptography protecting sensitive data use a FIPS 140-3 validated cryptographic module — not just "strong crypto," but a module that has been independently tested and certified by a NIST-accredited lab (with a CMVP certificate number). The distinction is real: a correct AES implementation that isn't on a validated module does not meet the requirement.

What it means in engineering practice. You run your crypto in FIPS mode (the OS/library's validated module, e.g. a FIPS-validated OpenSSL, the OS crypto provider, or a validated HSM), which restricts you to approved algorithms and key sizes and disables non-approved ones. You maintain a crypto inventory: where sensitive data is encrypted, which module/cert provides it, and that nothing sensitive uses a non-validated path. The boundary of the validated module matters — using a validated library incorrectly (outside its tested configuration) breaks the validation.

Misconception to kill now. "We use AES-256, so we're FIPS-compliant." FIPS requires a validated module (a CMVP certificate), used in its approved mode. Your own correct crypto, or a strong library not running in FIPS mode, does not satisfy it.

Chapter 8: The Regime Map — PCI, HIPAA, SOC 2, ISO, CMMC

The same engineering discipline (requirement → control → test → evidence) maps across regimes; know what each is for:

  • FedRAMP — US federal cloud; NIST 800-53 baselines; the most prescriptive; 3PAO + ConMon.
  • DoD IL2–IL6 / CMMC — defense; layered on FedRAMP with additional controls for controlled unclassified information (CUI) and classified levels.
  • PCI DSS — prescriptive controls for cardholder data environments; an Attestation of Compliance (AoC) via a QSA (Qualified Security Assessor — the accredited PCI auditor, PCI's analog of FedRAMP's 3PAO); scope is defined by the cardholder-data environment (CDE) — minimizing scope is the game.
  • HIPAA — safeguards (administrative/physical/technical) for protected health information (PHI); less prescriptive, risk-based; Business Associate Agreements.
  • SOC 2 — AICPA Trust Services Criteria (security, availability, confidentiality, processing integrity, privacy); an audit report (Type I = point in time; Type II = operating effectiveness over a period) — the common enterprise-SaaS bar.
  • ISO/IEC 27001 — an Information Security Management System (ISMS) with Annex A controls; a certification; internationally recognized.

The cross-cutting skill: map one set of engineering controls to many regimes (a single "encrypt data in transit, enforced and tested" control satisfies a FedRAMP SC-8, a PCI requirement, a HIPAA technical safeguard, and a SOC 2 criterion). Building the control once and mapping it is how you avoid doing the same work N times.

Misconception to kill now. "Each framework needs a separate program." The controls largely overlap; a well-engineered control library with a crosswalk (which control satisfies which requirement in which regime) lets one implementation serve many authorizations.

Chapter 9: Automated Evidence and the Audit

Evidence is the bottleneck. The slowest, most painful part of any authorization is evidence collection — proving each control operates. The principal-level move is to automate evidence:

  • pull control evidence from live sources (cloud config queries, CI test results, IaC scans, IAM exports) rather than screenshots;
  • attach a freshness requirement to each control (Phase 07 — a control whose evidence aged past its cadence is failing);
  • express it in OSCAL assessment-results so the auditor consumes data, not a binder.

This is the same "verify effective state, not configured intent" discipline as Phase 05/07 — applied to the audit itself. It collapses an annual fire drill into a continuous, low-cost stream.

Misconception to kill now. "We'll gather evidence before the audit." Evidence gathered once is stale the next month (ConMon needs it monthly), and a manual scramble produces gaps. Automate it, keep it fresh, and the audit becomes a query.

Chapter 10: Building the Authorization as a System

Putting it together. A principal builds the authorization as an engineered system:

impact categorization (FIPS 199) → baseline selection (Low/Mod/High, controls as data via OSCAL)
   → control implementations (your controls) + INHERITANCE (provider, substantiated)
   → automated evidence (live sources, freshness) → readiness engine (Lab 01: implemented/inherited/POA&M?)
   → 3PAO assessment → ATO → ConMon (Lab 02: monthly scans, POA&M SLAs, deviations) forever

The two labs are the engines at the heart of this: the authorization-readiness engine (is every baseline control satisfied, inherited-with-provider, or tracked in an on-time POA&M?) and the ConMon/ POA&M engine (are scans fresh and findings remediated within their severity SLA?). Together they turn "are we authorizable, and are we staying authorized?" from a human reading documents into a computed, continuous answer.

Misconception to kill now. "Compliance is the security team's tax." Engineered well, the authorization is the security program's external validation and forcing function — fresh evidence, enforced remediation SLAs, and a continuously-computed posture. It makes the company demonstrably trustworthy to the customers who require it.

Lab Walkthrough Guidance

The two labs are the engines of an authorization:

  1. Lab 01 — Control & Authorization-Readiness Engine. Build assess_authorization_readiness: baseline selection (nested Low/Mod/High), control inheritance (must name a provider), evidence requirements, and POA&M handling (a gap needs an open, on-time POA&M). This is "are we authorizable?" computed from OSCAL-style control data (Chapters 2–5).
  2. Lab 02 — Continuous Monitoring / POA&M SLA Engine. Build assess_conmon: monthly scan cadence, severity-based remediation SLAs (30/90/180), approved/unexpired deviations, and vendor-scope separation. This is "are we staying authorized?" (Chapter 6).
LAB_MODULE=solution pytest -q
pytest -q

Success Criteria

You are ready to apply this track when you can, without notes:

  1. Frame a compliance framework as a requirements spec and explain compliance-as-engineering.
  2. Explain NIST 800-53 families, baselines, and impact-driven baseline selection.
  3. Walk the FedRAMP ATO process (SSP, 3PAO, SAR, POA&M, AO) and explain authorizing with open POA&Ms.
  4. Explain the authorization boundary and substantiated control inheritance.
  5. Explain OSCAL / compliance-as-code and the leverage it provides.
  6. Explain ConMon: scan cadence, severity SLAs (30/90/180), and deviation requests.
  7. Explain FIPS 140-3 validated modules vs "strong crypto."
  8. Map one engineered control across FedRAMP/PCI/HIPAA/SOC 2/ISO.

Interview Q&A

Q: Can you get a FedRAMP ATO with open findings? A: Yes — an ATO doesn't require zero findings. Every gap must be tracked in an open POA&M with a remediation date, and the Authorizing Official must accept the residual risk. A gap without a POA&M, or an overdue one, blocks authorization. Mature compliance manages risk transparently; it doesn't pretend it's zero.

Q: What is control inheritance and why must it be substantiated? A: When you build on an already-authorized IaaS, you inherit the controls the provider owns (physical, hypervisor, much of network/media protection) — the shared-responsibility model formalized. The inheritance claim must name the authorized provider and be real for your usage; an inherited control with no named provider (or claiming coverage the provider doesn't give) is a finding. Inheritance shrinks the work; the controls above the line are still yours.

Q: Explain FedRAMP continuous monitoring SLAs. A: Monthly authenticated OS/web/DB scans (a scan older than ~30 days is a deliverable failure), and POA&M remediation by severity — High 30 days, Moderate 90, Low 180 from detection. An approved, unexpired deviation (false positive / risk adjustment / operational requirement) stops the clock; an expired or absent one doesn't. The AO can revoke the ATO if ConMon lapses.

Q: "We use AES-256, so we're FIPS-compliant" — correct? A: No. FIPS 140-3 requires an independently validated cryptographic module (a CMVP certificate), used in its approved FIPS mode with approved algorithms. Your own correct AES, or a strong library not running in FIPS mode, doesn't satisfy it. You maintain a crypto inventory mapping sensitive-data encryption to validated modules.

Q: How is "compliance as code" different from a compliance binder? A: OSCAL makes controls, baselines, SSPs, assessment results, and POA&Ms machine-readable, so a tool can validate authorization readiness continuously (every baseline control implemented/inherited/POA&M'd with fresh evidence) instead of a human reading narratives once a year. Inheritance and evidence become data; the audit becomes a query. It's the shift-left/automate discipline applied to the authorization itself.

References

Standards and programs

  • NIST SP 800-53 Rev. 5 (control catalog); SP 800-53B (baselines); FIPS 199 (impact categorization); FIPS 140-3 (cryptographic module validation) and the NIST CMVP.
  • FedRAMP documentation (SSP/SAR/POA&M templates, ConMon strategy, the authorization process); NIST SP 800-37 (Risk Management Framework).
  • OSCAL (NIST Open Security Controls Assessment Language) specification and tooling.

Other regimes

  • PCI DSS v4.0; HIPAA Security Rule; AICPA SOC 2 Trust Services Criteria; ISO/IEC 27001/27002; CMMC and DoD Cloud Computing SRG (impact levels).

Tooling / practice

  • OSCAL tooling (Trestle, compliance-trestle); cloud config/evidence automation; OpenSCAP; open-source GRC/"compliance as code" projects.
  • Phase 03 (secure SDLC, vuln management) and Phase 07 (cloud compliance mapping) cross-references.