PL-08 Security and Privacy Architecturespl-8
Whether an AWS call fetches evidence for this control, and what to run. Its Rev5 baselines, the indicators that reach it and the FedRAMP guidance attached to it open below.
Nothing names itNo recipe names PL-08. 7 reach an indicator it shares, which is adjacency and not coverage — worth reading, not worth recording as evidence for this control.
Collect evidence (0)
Authored AWS and pipeline recipes whose output is evidence for PL-08. This mapping is this project’s opinion (AWS overlay v3.0.0, pipeline overlay v0.8.0), versioned separately from the dataset — the upstream FedRAMP rules name none of these tools.
No authored recipe names PL-08. The nearest authored work is below.
The security and privacy architecture description is a written artifact reviewed for coherence with the SSP; a resource inventory is evidence about the deployment, not about the document.
This project’s assessment (automation register v0.9.0, reviewed 2026-08-04), versioned separately from the dataset and from the evidence overlays. It is an opinion about the AWS surface on that date, and the surface moves.
The KSIs that reach it are KSI-PIY-RSD, KSI-SVC-EIS — which is what asks for it. The evidence it asks for is written, not fetched. Browse /collect for the whole authored corpus.
Reaches the same indicator, not PL-08
These recipes prove a KSI that reaches it. None of them claims PL-08 — treat them as neighbours worth reading, not as coverage.
- The rule requiring the designated owners of the changed code to approve before it merges, the file that names who those owners are, the platform's own report of whether that file actually parses — and, per change, who approved, on which commit, and when. via KSI-PIY-RSDpipeline
- Which policy decisions were actually enforced against the infrastructure definitions the boundary deploys from: that a policy scan ran, on which branch, how many rules it applied and when it last ran, together with the failures still open and the record of which were dismissed and with what justification. The load-bearing half is the scan record rather than the findings. SA-08 asks whether security engineering principles were applied, and a clean findings list is the same output whether every principle held or the scan applied no rules, ran last quarter, or parsed nothing — so the count of rules run and the date it ran are the part of this evidence that makes the rest of it mean anything. via KSI-PIY-RSDpipeline
- For a service that ships code to a browser, the two things a pipeline can say about the mobile code it delivers: what was allowed INTO it, and whether what shipped is what this pipeline built. The first is the dependency diff for the change — every component added, its ecosystem, its version, its licence and any advisory against it, separated by whether it reaches the runtime or stops at the build — and the gate that makes the check mandatory rather than advisory. The second is a provenance attestation over the built bundle, verified against the repository and workflow that are supposed to have produced it. Neither is a statement about which mobile code technologies the organization decided to permit, and that is the control's first limb. via KSI-PIY-RSDpipeline
- AWS Config compliance results proving the network boundary is controlled — no security group exposes SSH to the internet, groups open to 0.0.0.0/0 only allow authorized ports, and every VPC's default security group denies all traffic via KSI-SVC-EISaws
- AWS Config compliance results proving continuous security monitoring is switched on account-wide — GuardDuty threat detection enabled (optionally centralized to a delegated admin) and Security Hub aggregating control findings via KSI-SVC-EISaws
What NIST requires of PL-08
The control statement from NIST 800-53 Rev5, verbatim. Square brackets are organization-defined parameters — yours to set, not FedRAMP's to dictate.
a. Develop security and privacy architectures for the system that: 1. Describe the requirements and approach to be taken for protecting the confidentiality, integrity, and availability of organizational information; 2. Describe the requirements and approach to be taken for processing personally identifiable information to minimize privacy risk to individuals; 3. Describe how the architectures are integrated into and support the enterprise architecture; and 4. Describe any assumptions about, and dependencies on, external systems and services; b. Review and update the architectures [frequency] to reflect changes in the enterprise architecture; and c. Reflect planned architecture changes in security and privacy plans, Concept of Operations (CONOPS), criticality analysis, organizational procedures, and procurements and acquisitions.
NIST SP 800-53 Rev5 catalog 5.2.0, from usnistgov/oscal-content at 78650f0. The FedRAMP dataset carries no control text; this is borrowed and pinned.
Rev5 baseline membership
Membership is the whole relationship — a baseline is a set of control ids. Class A carries no baseline at all. The Low/Moderate/High labels are an interpretation from control counts, not a dataset fact.
KSI indicators reaching this control (2)
Under 20x, these indicators are how this control is demonstrated — automated KSI evidence stands in for narrative control evidence.
- PIYKSI-PIY-RSDReviewing Security in the SDLC
The effectiveness of building security and privacy considerations into the Software Development Lifecycle and aligning with CISA Secure By Design principles is persistently reviewed.
- SVCKSI-SVC-EISEvaluating and Improving Security
Information resources are persistently evaluated for opportunities to improve security and those improvements are persistently made.
Pages exist for the 209 controls reached by at least one KSI. Baseline-only controls are the orphans on /coverage. Control titles and full text live in the NIST catalog, not this dataset.