SA-5, System Documentation, asks the organization to obtain or develop two kinds of documentation for each system, component or service, to document attempts to get documentation that does not exist, and to distribute what it has to the right people.
Administrator documentation must describe secure configuration, installation and operation, effective use and maintenance of the security and privacy functions, and known vulnerabilities regarding configuration and use of administrative or privileged functions. User documentation must describe the security functions users can reach and how to use them well, how users can interact with the system more securely and protect privacy, and user responsibilities in keeping the system secure.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference, and the thing a customer will ask for when they want your security configuration guide.
What it means in practice
The guidance says documentation helps staff understand how controls are implemented and run. It can set out roles, responsibilities and expectations between developer and organization, and it supports supply chain risk management, incident response and flaw remediation. People who need it include system owners, security officers and administrators.
Secure operation includes the awkward moments: first start, and resuming safe operation after a lapse. Document both.
The guidance is also honest about missing documentation. It might not exist because the system is old or the vendor has gone. You are expected to document your attempts to get it, such as contacting the manufacturer or searching the web, and to take an organization defined action in response. If the documentation is essential to operating controls, you may need to recreate it.
Protection matters too. Documentation is protected in line with the system's categorization, and documentation that describes vulnerabilities may need more. An internal runbook that lists known weak spots is not something to leave on a public wiki.
The enhancements add detail on what to obtain: SA-5.1 Functional Properties of Security Controls, SA-5.2 Security-relevant External System Interfaces, SA-5.3 High-level Design, SA-5.4 Low-level Design and SA-5.5 Source Code.
Evidence to collect
- An administrator guide per system, with secure install, configuration and operation sections.
- A user guide or security notes for end users.
- A record of requests for missing documentation, with dates and responses.
- Access controls on the documentation repository, showing who can read the sensitive parts.
- A distribution list, and proof that new staff and new owners received the documents.
- A change history showing documents were updated after releases.
Common gaps
Documentation that describes version one. Systems drift and the guide does not.
One person holds the knowledge. If the only copy of the restore procedure is in a single engineer's head, the control is unmet.
Known vulnerabilities written down but exposed too widely.
No record of failed attempts to get vendor documentation for legacy systems.
How to implement it
- List every system and mark whether admin and user documentation exists.
- For gaps, either write it or log your attempts to obtain it.
- Use a standard outline: secure install, baseline configuration, privileged functions, known risks, startup and recovery.
- Store the documents in a repository with access limits and version history.
- Add a documentation check to your release checklist.
- Review each guide yearly.
Software component lists are part of this picture. If you need to document what a build contains, generating an SBOM is the practical route, and the demo below shows how that works.
Click through it at your own pace, or open it full screen.
Quick check
What if the vendor no longer exists and the manual is gone?
Document your attempts to obtain it, take the action your organization defined, and recreate documentation if it is essential to operating the controls.
Who needs administrator documentation?
System owners, security officers and system administrators, according to the guidance.
