SI-16 Memory protection: requirements and evidence

What SI-16 memory protection requires and why assessors care

SI-16 requires the organization to define and apply safeguards that protect system memory from unauthorized code execution. It sits in the System and Information Integrity family, is assigned to the moderate and high baselines in SP 800-53B, and is marked in Appendix C of SP 800-53 Rev. 5 as implemented by the system and as an assurance-related control. If your system is categorized at moderate or high impact, or a customer or FedRAMP class requires it, you need a written answer to SI-16 that names the protections in use and shows they are configured. The risk being addressed is familiar: buffer overflows and similar memory corruption flaws let an attacker redirect execution into injected code. Data execution prevention, address space layout randomization and comparable platform features reduce how easily that happens, but the control asks you to define them and prove they are on, not simply to assume the operating system handles it. The control carries one organization-defined parameter and no control enhancements in Release 5.2.0, so the scope of your answer is set by how you fill that parameter and which components you name. Confirm the current parameter wording in the OSCAL catalog before drafting, because the assessment procedure for SI-16 is built around it. SP 800-53A Release 5.2.0 assesses the control through one determination statement, and its examine objects are a list of the safeguards protecting system memory, system design documentation, system configuration settings with their documentation, and system audit records. An assessor will therefore ask which safeguards you listed, where the design documentation describes them, what the live configuration shows, and whether audit records support that the settings persisted. Assessors care most about the gap between a policy sentence and a configuration they can see. What makes SI-16 hard is rarely the purchase of a product. The work is inventory, configuration and proof across every operating system image, container base, virtual machine template and runtime in the boundary, including hosts that were built years ago. Ask your team to produce a list of the memory protections per platform, the setting that enables each one, and the method that will show its state on demand. Then decide whether the evidence will come from configuration baselines, a scanner, or a fleet query tool. Open-source options such as osquery and Wazuh can report configuration state across endpoints, but you must confirm that a given check covers your specific protection on your specific platform before relying on it. Related controls such as AC-25, SC-3 and SI-7 will be examined alongside SI-16, so plan the evidence once.

Which systems and platforms fall under SI-16 scope

SI-16 applies to the system as a whole, so scope starts with every component that runs code in memory. The decisions below determine which components carry the control, which baseline sets the bar and which protections the provider already supplies.

Operating systems on each host

Every operating system that runs on a system component is a candidate for SI-16 evidence, including server, endpoint and appliance images. Confirm which memory protections each kernel and distribution enables by default, such as data execution prevention and address space layout randomization, and whether administrators can disable them. Record the configuration that is actually in force on each image, not only the one in the build template.

Hypervisors and virtualization hosts

Hypervisors execute guest workloads and sit beneath every virtual machine, so their memory protections affect all guests at once. Decide whether the hypervisor is in the system boundary or inherited from a provider, and document the protections it enables. Ask who patches the host, how memory protection settings are verified after updates and where the configuration evidence is stored.

Runtimes and container hosts

Language runtimes, JVMs, interpreters and container hosts all allocate executable memory and can weaken protections the operating system provides. Inventory the runtimes that run in the system, note any that request executable memory regions, and check whether container hosts apply the kernel protections to workloads. Treat each runtime version as a component whose settings must be evidenced.

Endpoints and administrator workstations

Endpoints that connect to the system are often outside the server build process and can run with weaker memory protection settings. Decide whether endpoints are in the SI-16 boundary or only in the boundary for related controls such as SI-3. Confirm the operating system build and memory protection state on each device class, and use endpoint management tooling to collect that state rather than relying on manual checks.

Inherited protections from the cloud provider

A cloud or hosting provider may supply memory protections for the physical hosts and hypervisor layer, which the organization can inherit rather than reimplement. Obtain the provider's control documentation, confirm which parts cover SI-16 and identify the gap that remains for the organization's own images and runtimes. Inheritance must be documented in the system security plan, with the provider's evidence referenced.

Baseline and FedRAMP Class C and D

SP 800-53B assigns SI-16 to the moderate and high baselines, so a low-impact system does not carry it by default. FedRAMP's Rev5 baselines require SI-16 at Classes C and D, which makes the control mandatory for those cloud offerings. Confirm the impact level and FedRAMP class with the authorizing official before scoping, because the answer decides whether SI-16 evidence is a requirement or a recommended practice.

How an assessor tests SI-16 across examine, interview and test

Examine is the method where the assessor reviews documents, configurations and records to establish what the organization says it has in place. For SI-16, the SP 800-53A determination statement asks whether the system's memory protections are defined and in place, and the examine objects are the artifacts that describe them. The assessor is looking for a written, specific account of which safeguards apply and how they are configured, not a general statement that memory is protected.

List of security safeguards: The assessor expects a list naming the protections in use, such as data execution prevention and address space layout randomization, with the platforms they cover.
System design documentation: This shows where the protections sit in the architecture and which components rely on them, so the assessor can judge coverage.
System configuration settings and related documentation: Kernel, operating system and runtime settings that enable the protections, with the documents that explain each setting and its owner.
System audit records: Logs or change records that show the settings were applied and have not been silently reverted.

To prepare, check that each safeguard on the list maps to a configuration item you can show, and that the design documentation and the configuration baseline describe the same system.

How to implement SI-16 step by step

This sequence turns the SI-16 requirement into a documented, configured and monitored set of memory protections, with an artifact at each stage that an assessor can examine against the SP 800-53A procedure.

Define memory protections for each platform
The system owner, with platform engineering and security, lists the memory protections each operating system, container runtime and application runtime in scope must provide, such as data execution prevention and address space layout randomization. Work from the vendor's documented options for each platform and confirm each one is available and enabled by default on the versions you run. The output is a platform-by-protection matrix approved by the authorizing official or the equivalent owner. Confirm the exact protection names and defaults with each vendor, since these vary by platform and version.
Set the organization-defined parameter
SI-16 has one organization-defined parameter in Release 5.2.0, so the organization must state, in its SI policy or system security plan, the specific memory protections it requires. Record the value as a written decision with an owner and a review date set by your own governance process. The output is a completed parameter statement that the assessor can match against the control text and the system design documentation.
Document the safeguard list
Compile the safeguards that protect system memory from unauthorized code execution into a single list, mapping each one to the systems and system classes where it applies. Include the related controls AC-25, SC-3 and SI-7 where they carry part of the protection, so the reader can see the dependencies. The output is the safeguard list itself, which SP 800-53A names as an examine object, and it should be kept under configuration control with the system design documentation.
Configure and verify settings by system class
Engineers apply the required settings to each system class, such as Linux servers, Windows endpoints, container hosts and application runtimes, and record the configuration in the configuration baseline. Verification means checking the live settings on a sample of each class, not only the template. The output is a configuration record and verification results per class, which map to the system configuration settings examine object in SP 800-53A. Where a protection cannot be enabled, route the case to step six.
Monitor for configuration drift
Schedule recurring checks that compare each endpoint or host against the documented settings and alert on deviations. Open-source tools can run these checks: Wazuh Security Configuration Assessment evaluates endpoints against YAML policies that can be extended with custom checks, Fleet policies ask yes or no questions of devices through osquery and report which devices pass or fail, and osquery can schedule queries across a fleet. Confirm which settings each tool can check on your platforms before you rely on it. The output is a drift report with a named owner for each failing device and the audit records of those checks, which correspond to the system audit records examine object.
Record and review exceptions
Where a host cannot enable a required protection, document the exception with the technical reason, the compensating measures, the affected systems, the risk acceptance and the planned remediation. The authorizing official or designated owner approves each exception, and the list is reviewed on the cadence your governance process sets. The output is an exception register linked to the plan of action and milestones, so an assessor can confirm that every gap is known, accepted or remediated.

What evidence passes an SI-16 assessment

For SI-16 Memory protection, an assessor cares far more about configuration evidence than about a policy that says memory protections exist. The SP 800-53A Release 5.2.0 procedure for SI-16 has one determination statement and examine objects that point at concrete artifacts: a list of the security safeguards protecting system memory from unauthorized code execution, system design documentation, system configuration settings with their associated documentation, and system audit records. A policy paragraph satisfies none of these on its own. The practical goal is to show that the safeguards named in the design are the ones actually enabled on each system in scope, and that someone checks this over time.

Start with a current safeguard list. For each system in the boundary, name the protections in use, such as data execution prevention and address space layout randomization at the operating system level, any runtime or container protections, and any compiler or kernel hardening the team relies on. Pair that list with design documentation that explains where each protection sits and why it covers the system's workloads. Then export the actual configuration settings from representative hosts, images and container templates, along with the documentation that explains each setting. An export from one golden image proves little if production hosts drifted. Confirm the sampling approach with your assessor before you collect evidence.

Audit records close the loop. Show recurring checks that compare live settings with the approved baseline and record deviations and their remediation. Osquery can run such queries across a fleet on a schedule, Fleet policies can report which devices pass or fail a yes-or-no check, and Wazuh's Security Configuration Assessment can compare endpoints with YAML policies and log the results. Confirm with the assessor which tool outputs they will accept as audit records. Finally, check that the evidence matches the organization-defined parameter for SI-16 and the baseline in use: the moderate or high baseline, or a FedRAMP class that also requires SI-16. A parameter value that the design never mentions is a common reason for a finding.

Evidence artifacts to keep current between audits

SI-16 is a control an assessor tests through documents and configuration records, so the evidence has to exist before the assessment starts and stay accurate afterward. The six artifacts below form one chain: the safeguard list defines what must be true, configuration exports and design documents show how it is achieved, scan results and drift records show whether it stayed true, and exceptions explain every gap.

Safeguard list for system memory

This is the written inventory of the safeguards that protect system memory from unauthorized code execution, such as data execution prevention and address space layout randomization, with the platforms and hosts each one covers. SI-16 has one organization-defined parameter, so the list is where your chosen parameter values are recorded. Review it whenever a new operating system image, container base or hypervisor enters the environment, and confirm each entry names an owner and the setting it depends on.

Platform configuration exports

Export the memory protection settings from each self-hosted platform and host image on a schedule, and store the exports with the date and the identity of the system that produced them. Exports should show the actual running state, not only the intended template, so an assessor can compare them against the safeguard list. Keep the export tooling itself under version control so the query used to produce each export can be reproduced later.

Design documentation for memory protections

Architecture and system design documents should explain which memory protections are enabled, why they were chosen, and which components cannot use them, such as legacy binaries or vendor appliances. Assessors examine this documentation as well as the configuration. Update it when a hardware platform, kernel version or compiler toolchain changes, and record the date of each revision so the document can be matched to the configuration in force at the time.

Compliance scan results over time

Keep dated results from configuration assessment and fleet policy checks for memory protection settings, not only the most recent run. Trend data shows whether a control held across the period between audits or was fixed just before the assessment. Wazuh configuration assessment and Fleet policies can both produce pass or fail results per host. Confirm which policy versions were active on each date, because a result is only meaningful against the rule set that produced it.

Audit records of drift findings

When a host reports a memory protection setting that differs from the approved baseline, record the detection time, the host, the affected setting, the responder and the corrective action. Drift records show that the monitoring works and that findings were acted on, which assessors test through audit records. Review open drift items at a fixed cadence so a finding that was never closed does not disappear between reviews.

Documented exceptions with approvals

Some hosts cannot enable every memory protection, for example because of a vendor constraint or a legacy workload. Each exception should name the host, the protection it lacks, the compensating measures, the risk owner who accepted it, the approval date and an expiry or review date. Record each exception in the same system as your plan of action and milestones so the exception is tracked until it closes. Exceptions without an expiry date tend to become permanent gaps.

What meeting SI-16 costs in money and effort

This table breaks the cost of meeting SI-16 into components, showing who is paid, whether each cost is one-time or recurring, what drives it and how to reduce it. No supplied source gives a figure for these costs, so use the table to shape a quote request rather than to estimate a budget. Self-hosted open-source tooling mainly removes license spend, not the engineering and evidence work.

Cost component	One-time or recurring	What drives it	How to reduce it
Tooling or licenses	Recurring if commercial, otherwise minimal	Commercial memory protection or endpoint hardening products, and per-endpoint or per-core pricing. Open-source options such as osquery or Wazuh remove license spend but not operating cost.	Confirm which platforms already provide DEP and ASLR settings, then add only the checks you cannot run with existing tools. Ask the vendor for licensing that matches your endpoint count.
Engineering time to configure platforms	One-time, with periodic rework after OS upgrades	Number of operating system builds, whether memory protection settings are enforced by policy or by hand, and how many systems fall outside the standard image.	Standardize images so DEP and ASLR are set once in the baseline. Write policy checks as code so the same query runs on every host.
Evidence upkeep	Recurring	How often configuration changes, how many systems must show current settings, and whether exceptions are documented with approvals and dates.	Schedule automated queries that record memory protection state, and keep exception records in the same system that holds configuration baselines.
External review or testing	Recurring, usually per engagement	Scope of the assessment, whether memory protection is tested only by configuration review or also by exploit-resistance testing, and the number of system types included.	Define in the written scope which systems and settings are tested. Ask for a fixed-scope quote with deliverables listed separately from retesting.
Auditor sampling	Recurring, tied to each assessment cycle	How many systems the assessor samples, whether the assessor requests raw query output or only summaries, and whether the organization can show history over the period.	Keep dated, exportable evidence per system, so the assessor can sample without staff rebuilding reports. Confirm the sample approach with your independent assessor before the test.

Who does what for SI-16: your team, a partner and the auditor

Your organization owns SI-16. Accountability for memory protection stays with the system owner and the authorizing official or equivalent decision maker, even when a partner configures the systems and gathers evidence. SI-16 has one organization-defined parameter in Release 5.2.0, so your team must decide which safeguards count as protecting system memory from unauthorized code execution and document that choice in the system security plan. Those decisions are risk decisions, and they belong to you.

Parameter and scope decisions: Define the safeguards you rely on for each system class, such as the operating system protections and the runtime settings for your application stacks.
Exceptions and risk acceptance: Record any component that cannot enable a protection, along with compensating controls and who accepted the residual risk.
Policy and ownership: Assign a named owner for SI-16 and tie it to the SI-1 policy and procedures.
Remediation funding and sequencing: Decide which systems are upgraded first and who approves downtime.
Signed evidence: Confirm that the system security plan and any plan of action and milestones match what is actually running.

Before engaging anyone, confirm with your assessor which baseline applies to each system, since SI-16 appears only in the moderate and high baselines.

Where organizations fall short on SI-16

Most SI-16 findings are not about missing protections. They come from settings that were never defined, applied unevenly, inherited without documentation, or proven only once. Each gap below is something an assessor can test against the examine objects in SP 800-53A, and each has a closing action an organization can take before the assessment starts.

No defined parameter

SI-16 has one organization-defined parameter, so the organization must state which memory protections it requires, such as data execution prevention and address space layout randomization, and on which component types. Without that definition, the system cannot be tested against it, and staff argue about whether a platform default counts. Closing action: write the parameter as a named list of protections per platform type and reference it from the system security plan.

Protections enabled on some platforms only

Memory protections are often on for newer servers and off for legacy images, container hosts or appliances that were installed earlier. An assessor examining configuration settings will sample across the system, so one unprotected class of host can fail the control. Closing action: inventory every operating system and runtime image in scope and record the protection state of each one, not just the primary build.

Inherited cloud protections not documented

Cloud providers and managed platforms often supply memory protections that the customer cannot see or change. Teams then assume the control is covered without stating which layer provides it, who owns it and what evidence proves it. An assessor will ask for the responsibility split in writing. Closing action: document each inherited protection, its provider source and the customer evidence that confirms it is active.

No drift monitoring

A host that passed a hardening check at build time can lose a protection after a kernel update, a boot parameter change or a manual exception. Without scheduled checks, the organization learns about the drift only during the assessment. Closing action: schedule automated queries or configuration assessments that report the protection state of each host and alert on any change.

Exceptions without approval

Some legacy workloads cannot run with every protection enabled. When those exceptions are made by engineers without a documented risk decision, the control appears met on paper while the gap remains unmanaged. Closing action: route each exception through a named risk owner, record the compensating measures and set a review date tied to the plan of action and milestones.

Evidence that shows a setting once

A screenshot or a single configuration export proves the protection was on at one moment. SI-16 is assessed as a control that operates over time, so the evidence must show the state across the assessment period and across the fleet. Closing action: keep dated, repeatable reports of protection state per host and retain them with the assessment package.

SI-16 questions buyers ask before hiring help

How much effort does SI-16 memory protection take to implement?

SI-16 is a single base control with one organization-defined parameter and no enhancements, so the requirement itself is narrow. The effort lies in proving that memory protections are active across the system. Teams usually confirm which protections the operating system, container runtime and application stack provide, record their configuration, and show that the settings are applied consistently. The SP 800-53A assessment procedure asks for a list of safeguards, design documentation, configuration settings and audit records, so the bulk of the work is building that evidence set for each platform in scope.

Can our own team implement SI-16 without an outside partner?

Often yes, if your engineers can read operating system and runtime configuration and your assessment team can map the evidence to the SP 800-53A procedure. Many organizations keep ownership of the control and the policy, and bring in help only for configuration hardening, evidence collection across many hosts, or independent review before an assessment. Confirm internally who owns the control, who will answer assessor interviews, and who will maintain the settings after go-live. The organization always owns its controls; an implementation partner prepares systems and evidence.

How long does SI-16 work take, and what drives the timeline?

No supplied duration exists for SI-16, so treat any figure you hear with caution and ask for the basis. The timeline depends on the number of systems in scope, how many operating system and runtime platforms they use, whether memory protection settings are already enabled and documented, and how quickly your change process can apply hardening changes. Assessment scheduling, the availability of staff for interviews, and any remediation of findings also affect the calendar. Ask any provider to break the timeline into discovery, configuration, evidence collection and assessor support, with dependencies named.

What does the team need to provide for SI-16 work?

The work needs access to system design documentation, configuration baselines, and a representative sample of the platforms where memory protection applies. Expect to provide the following:

A list of systems, operating systems, container images and runtime environments in scope
Administrative access or read-only configuration exports for hosts and build pipelines
Change approval for any setting that affects application compatibility
Named staff who can explain how the system is operated and who will sign off on the evidence

Identify these owners early, because assessor interviews rely on them.

How does SI-16 relate to FedRAMP Classes C and D?

FedRAMP's Rev5 baselines require SI-16 at Classes C and D, so a cloud service pursuing those classes must show memory protection controls and evidence for them. SI-16 also appears among the related controls for two FedRAMP 20x Key Security Indicators, KSI-CNA-MAT and KSI-PIY-RSD, which connects it to attack surface and secure development reviews. Confirm the current class requirements and indicator mappings in the FedRAMP reference and rules before scoping, because they are updated over time. Ask your assessor which FedRAMP evidence format they expect.

Does DeployOpen issue the SI-16 assessment or certify our system?

No. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. Only an independent assessor, auditor or certification body issues reports or certificates. DeployOpen can help configure memory protection on the platforms it deploys and assemble the evidence an assessor will request, but the organization owns the control and the assessor makes the determination.

What does a fixed-scope DeployOpen quote cover for SI-16?

DeployOpen engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. Ask that the scope name the systems and platforms covered, the memory protection settings to be verified or applied, the evidence artifacts to be delivered, the assessor-facing materials, and what is excluded, such as remediation of unrelated findings. Ask separately whether ongoing support or retainer work is needed after the initial delivery, since that recurs.

Where to read the SI-16 text and assessment procedure

The authoritative text for SI-16 Memory protection sits in the NIST SP 800-53 Rev. 5 catalog, and the baseline assignment sits in SP 800-53B. Start with the SP 800-53 Rev. 5 publication page on CSRC for the control statement and supplemental guidance, then open the SP 800-53B baselines page to confirm that SI-16 is assigned to the moderate and high baselines. The paragraph of SP 800-53B you need is the one that lists baseline membership, so check it against the baseline you are targeting rather than assuming it from memory.

The assessment procedure is in SP 800-53A, and the most practical way to read it alongside the control is the machine-readable Release 5.2.0 OSCAL files in the usnistgov/oscal-content repository. The OSCAL JSON catalog carries the SI-16 statement, its organization-defined parameter and the assessment objects that an assessor will ask to see, such as configuration settings, system design documentation and audit records. Note which release each file reflects, because the catalog and procedures are versioned separately from the printed PDFs.

Before you write your own control statement, confirm the wording against the current release on CSRC and in the OSCAL files, and check whether your assessor or sponsoring authority expects a specific release. NIST issues changes as numbered releases, so text you copied from an older document may differ. Ask your assessor which release and which baseline they will test against, and record that choice in the system security plan so the SI-16 statement and the assessment procedure refer to the same version.

How DeployOpen prepares SI-16 systems and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so memory protection settings, monitoring and evidence are built into the environment rather than assembled at audit time. We prepare systems and evidence for your assessment, while your organization owns the control and an independent assessor reaches the conclusion.

How we scope

We agree a written scope listing the systems, hosts and platforms where SI-16 memory protections must be in place.
We confirm the organization-defined parameter for SI-16 with your control owner before any configuration work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

We verify that data execution prevention and address space layout randomization are enabled on each in-scope operating system and platform image.
We document the safeguards protecting system memory from unauthorized code execution in the system design documentation.
We configure osquery and Fleet policies to report whether memory protection settings remain in place on each endpoint.

How we hand over

We deliver a configuration record and a sample set of audit records showing the settings were applied and checked.
We provide the evidence package mapped to the SI-16 examine objects so your assessor can trace each item.
We train your team to rerun the checks and explain which results need attention, so the evidence can be refreshed without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover re-verification after operating system upgrades, image rebuilds and changes to the memory protection configuration.
We confirm with your assessor which evidence format and frequency they expect before the retainer scope is set.