SC-27 Platform-independent Applications says to include within your systems a chosen set of applications that can execute on more than one platform. The guidance gives the reason. Portability lets you rebuild on a different platform if a particular operating system is under attack.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog.
What it means in practice
You choose the applications. A container image that runs on Linux hosts from two providers qualifies. So does a web application that works in any modern browser. The point is a way to restore service when one platform is compromised or unavailable.
Note what the control does not ask. It does not ask every application to be portable. It asks you to include a defined set. That makes scope your decision, and your auditor will want to see how you picked it, usually by tying it to the mission critical functions in your business impact analysis or continuity plan.
Portability also helps supply chain events. If one base image or operating system release ships a bad update, a second platform gives you somewhere to run.
Evidence to collect
- The named list of platform independent applications.
- A build that produces artifacts for more than one platform.
- A restore test that ran the application on an alternate platform.
Common gaps
The application is portable in theory, but nobody has ever run it elsewhere. Another gap is a hard dependency on one cloud service.
How to implement it
Start with the one or two applications whose outage would hurt most. Build them for a second environment, run a restore drill, and keep the result as your evidence.
Quick check
What proves portability?
A tested run of the application on a second platform, not a claim that it should work.
