Why: A stack built for swap forces deliberate external-service management: capabilities are chosen against defined criteria, adopted with exit paths, and replaceable when a provider's security posture degrades — which supplies the selection discipline and the leverage that this requirement's provider obligations depend on.
What this does not claim: May partially address the requirement: swap-ability creates the conditions for imposing security requirements on providers, but the imposing itself — contractual obligations, documented oversight, defined user roles per service — is separate work the practice does not perform. A replaceable service with no security terms in its agreement leaves the requirement's core untouched.
- Evaluate providers against defined security criteria before adoption
- Keep exit and migration paths current so provider obligations remain enforceable in practice
- Adoption decision records showing the security criteria applied
- The service register with exit paths and internal owners
Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06