Home NIST Guidelines PL-8(1)
PL-8(1) Planning

Defense in Depth

High Risk Moderate Medium Cost

PL-8(1) (Defense in Depth) enhances base PL-8 within the NIST Planning family. Base PL-8 sets the foundational expectation; this enhancement adds specificity: Design the security and privacy architectures for the system using a defense-in-depth approach that: Allocates [organization-defined] to [organization-defined] ; and Ensures that the allocated controls operate in a coordinated and mutually reinforcing manner. Organizations strate. Covered entities and business associates apply it to system security plans, rules of behavior, and security architecture for clinical systems holding ePHI.

Control Objective

Implement Defense in Depth so organization-defined planning safeguards operate consistently on systems and networks that handle ePHI, with measurable evidence for HIPAA and NIST assessments.

Implementation Guidance

  1. Map PL-8(1) to systems in scope (EHR, imaging, lab, pharmacy, billing, identity, backups, and BA connections).\n2. Translate “Defense in Depth” into technical settings, procedures, or architecture patterns owned by named roles.\n3. Prefer enforceable controls (config, automation, mediation) over awareness-only measures where feasible.\n4. Integrate with change, incident, and downtime processes so clinical operations are not surprised.\n5. Log and retain evidence of operation (tickets, configs, test results) aligned to audit needs.\n6. Include vendors/BAs in contracts and connection standards when they touch the control surface.\n7. Test after major EHR, network, or cloud changes — upgrades often reset protections.\n8. Review exceptions at least quarterly; expire “temporary” holes that expose ePHI paths.

Real-World Use Cases

How this control shows up in healthcare and HIPAA-covered environments.

Real-world scenario

Layered EHR boundary (PL-8(1))\nSecurity architecture documents defense-in-depth from edge WAF through microsegmentation to host controls. Evidence labeled for PL-8(1).\n\n### Supplier diversity for critical path (PL-8(1))\nArchitecture avoids single-supplier concentration for identity and backup of ePHI platforms. Evidence labeled for PL-8(1).\n\n### Architecture coordination forum (PL-8(1))\nClinical IT and security co-review major design changes before they enter the SSP. Evidence labeled for PL-8(1).

Best Practices

  • Name an owner for PL-8(1) in the SSP control matrix.\n- Favor system enforcement on ePHI paths over informal email approval.\n- Measure coverage: percent of in-scope clinical systems where the enhancement operates.\n- Review exceptions quarterly with security and clinical informatics.\n- Feed relevant events to SIEM with a named use case.\n- Keep a one-page evidence pack (config + sample log + last test) ready for assessors.

Common Gaps & Violations

  • Policy cites PL-8(1) but production EHR/network paths show no enforcement of defense in depth.\n- Permanent exceptions with no expiry for vendors or “special” clinics.\n- Control implemented only on corporate IT — clinical devices and interfaces omitted.\n- No logs or test records; reliance on tribal knowledge.\n- Major upgrade silently disabled the enhancement.

Required Documentation

  • Procedure/standard for Defense in Depth (PL-8(1))\n- Architecture or configuration baselines showing enforcement points\n- Exception register with owners and expiry\n- Sample logs, alerts, or test results\n- Training or runbook references for clinical/IT operators

How to Test & Validate

  1. Attempt a prohibited or out-of-policy action related to defense in depth; confirm block, alert, or required workflow.\n2. Complete an authorized clinical/IT path; confirm success and logging.\n3. Sample open exceptions for approval and expiry.\n4. Verify at least one EHR-adjacent and one BA/vendor path are in scope.\n5. Confirm evidence retained for the last 90 days (or per policy).

Audit Considerations

Assessors look for operating evidence of Defense in Depth on systems touching ePHI — configs, logs, restore/DR artifacts, or failed-test results — not only a policy paragraph referencing PL-8(1).

HIPAA Mapping

How this NIST control supports HIPAA Security Rule expectations.

  • 164.316(a) Policies and Procedures — implement reasonable and appropriate policies for ePHI safeguards.\n- 164.308(a)(1)(i) Security Management Process — plan security measures protecting ePHI.\n- 164.316(b)(1) Documentation — maintain written security plans and related records.\n- 164.306(a) Security standards — ensure CIA of ePHI through planned controls.

Compliance Tips

  • List PL-8(1) explicitly in the system security plan with system inventory references.\n- Prioritize emergency department, inpatient EHR, and remote access paths first.\n- Bundle evidence with related HIPAA evaluation, integrity, or workforce-security narratives where they overlap.

References & Resources

  • NIST SP 800-53 Rev. 5 — PL-8(1)\n- Related controls: PL-8, SC-2, SC-3, SC-29, SC-36

Related Guidelines

Related controls that commonly accompany PL-8(1).

PL-8 High

Information Security Architecture

PL-8 requires developing an information security architecture that describes how security requirements are allocated to system elements…
SC-2 High

Application Partitioning

SC-2 requires separating user functionality from system management functionality. When ordinary clinicians can reach EHR security consoles…
SC-3 High

Security Function Isolation

SC-3 requires isolating security functions from nonsecurity functions through isolation boundaries that control information flow and…

Need Help Implementing PL-8(1)?

Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.

Contact Our Experts View All Guidelines