SI-11 Error handling: requirements and evidence

What SI-11 error handling asks for and why errors become an attack surface

If your moderate or high system must pass an SP 800-53 assessment, nobody has likely reviewed what users and attackers see when something breaks. SI-11 requires that error messages give the information needed for corrective action without revealing details that could be exploited, and that the detailed content be revealed only to defined personnel or roles. In Release 5.2.0, SI-11 carries one organization-defined parameter and has no control enhancements, so the assessment turns largely on how you define that parameter and whether the behavior you configured matches the definition.

The risk is ordinary and easy to miss. A verbose error can disclose framework and library versions, file system paths, database table or query fragments, internal hostnames and, in unlucky cases, credentials or tokens that were logged during a failed call. Each detail narrows an attacker's search. The control is hard in practice because errors originate in many places at once: the web tier, application code, API gateways, databases, identity providers, container runtimes and third-party components. Developers need stack traces, operators need correlation identifiers and timestamps, and auditors need records that show what happened. Those audiences need different detail, and a single default setting rarely serves all of them.

Start by inventorying where errors reach users, not just where they are generated. Confirm with your application and platform owners which components return raw exception text to clients, which write full traces to logs that a broader group can read, and which error responses differ for authenticated and unauthenticated callers. Ask who your defined personnel or roles are for detailed diagnostics, and record that decision in the system documentation, because assessors will examine the structure and content of error messages, the design documents and configuration settings against it.

Which systems, error paths and teams SI-11 covers

SI-11 applies to systems in the moderate and high baselines, but the amount of work depends on which error paths, logs and third-party components fall inside the authorization boundary. Each card below is a scoping decision to settle with your assessor before evidence collection starts.

Systems in the moderate and high baselines

SP 800-53B assigns SI-11 to the moderate and high baselines, so the first decision is which systems carry those impact levels. Confirm the security categorization of each system in the boundary, because a system categorized as low does not inherit SI-11 even if it shares code with a higher-impact system. If a shared service is tailored or overlaid, record that decision in the system security plan so the assessor can trace it.

User-facing error pages and messages

Web forms, login screens, portals and mobile screens all return errors to people who may be attackers. Inventory each screen that can show a failure, including validation messages, timeouts and generic 500 pages. The check is whether a message gives a user enough to correct the problem without naming the database, framework, file path or the reason an account lookup failed.

API and machine-to-machine error responses

APIs often return verbose JSON with stack traces, SQL fragments or internal hostnames, and those responses are easy to automate against. Include every externally reachable endpoint and every internal service that other components call. Verify that production builds disable debug modes and that error bodies use a fixed schema, since an assessor will test these responses directly.

Error logs and monitoring pipelines

Detailed errors are needed for corrective action, so they are written somewhere. Decide which log stores, search indexes and alerting rules hold those details, and who can read them. Logs that hold stack traces or credentials are in scope for SI-11 and for the audit controls, so restrict access to the defined roles and confirm that the logs themselves are protected.

Managed and third-party components

Load balancers, CDNs, managed databases, identity providers and SaaS tools can generate error pages on the system's behalf. Those default pages often reveal vendor names, versions or internal addresses. List each managed component that returns output to users, confirm its configuration options with the vendor, and document any default you cannot change as a residual risk in the plan of action and milestones.

Development and operations teams

Error message text is written by developers, displayed by operators and read by assessors, so ownership needs to be explicit. Assign who approves message wording, who maintains the error catalog and who reviews changes to exception handling in the pipeline. Without that assignment, a new debug flag or verbose exception handler can reach production with no one accountable for the exposure.

How an assessor tests SI-11 with examine, interview and test methods

This table maps the two SI-11 determination statements to the examine, interview and test methods an assessor applies, the evidence each one requests and the findings that most often fail. Read each row as one step of the assessment, and use the evidence column to prepare the packet before the assessor arrives.

Assessment element	What the assessor checks	Evidence to prepare	Common finding
Determination statement 1: error message content	Error messages give enough detail for corrective action without exposing information that could be exploited	Written error message standard, sample responses for common failures, and the design rules that decide what a user sees	Stack traces, SQL fragments or file paths returned to end users
Determination statement 2: access to error detail	Detailed error information is revealed only to defined personnel or roles	Role definitions for who may view full error detail, plus the access settings that enforce them	Verbose error output visible to all authenticated or anonymous users
Examine: documentation of message structure and content	Whether the documented message format matches what the system actually returns	Error handling standard, message catalog and approved wording by error class	Documented standard exists but is not followed by the development team
Examine: system design documentation	How errors are caught, logged and rendered across tiers, including the API and front end	Architecture or design notes showing error paths, exception handlers and logging hooks	Design omits how third-party components or background jobs report errors
Examine: configuration settings and their documentation	Debug modes, verbose logging and detailed error pages are disabled in production	Exported production settings, deployment templates and a record of who approved each change	Debug flags left enabled after troubleshooting or in staging copies promoted to production
Examine: system audit records	Errors are recorded for administrators while users see only generic responses	Sample error log entries, log access records and evidence that detailed errors reach the right audience	Error logs exist but no one reviews them or access to them is not restricted
Interview: developers and operations staff	Whether staff know which details may appear in responses and where full detail goes	Named interviewees, their roles and the questions asked, recorded for the assessor	Staff describe the rule differently from the written standard
Test: trigger controlled failures	Forced errors produce generic user messages and detailed records only for authorized roles	Test scripts, input used, captured responses and matching log entries	Test shows full stack trace in the browser or API response under a common input error

How to design error responses that help users and leak nothing

SI-11 forces a design split that many applications never make on purpose. End users receive a short, generic message that tells them what to do next, such as retrying or contacting support, without describing what failed inside the system. Authorized operators and developers need a specific corrective message, and that message should be available only to the defined personnel or roles the organization names as the audience for error detail. The organization should write down who those roles are, where the specific messages appear (an administrative console, a restricted log view, a ticketing integration) and who can see them. Those decisions are the ones an assessor will ask about first, because the control turns on who is allowed to see what.

The third element is a detailed record kept in protected logs, with a correlation identifier that links the user-facing message to the full event. When a user reports that a request failed, support can quote the identifier, and the engineer who holds the log can reconstruct the stack trace, query and component involved without that detail ever reaching the browser or API response. Stack traces, SQL fragments, file paths, component versions and anything resembling a credential or token belong only in the protected record. Each of these reveals structure or secrets that help an attacker plan the next step. The reader should confirm that log access is itself restricted and reviewed, because a detailed log that anyone on the support desk can read defeats the split.

Enforcement works best in one place. A centralized error handler, or the framework setting that switches off debug output in production, catches unhandled exceptions and returns the generic response, so individual developers do not each need to remember the rule. Test this with deliberate faults in a pre-production environment and confirm that the response body, headers and error pages contain no internal detail. Include the check in code review and in security testing, and keep the handler's configuration under change control so that a debug flag cannot be switched on quietly during an incident. Each platform's exact settings for debug output and error pages differ, so confirm them against the vendor documentation for the versions you run.

Implementing SI-11 in a sequence of steps

This sequence turns SI-11 from a policy sentence into configured error handling that an assessor can test. Each step produces a named artifact, so the final package shows what roles may see, how errors look, where detail goes and how the behavior was verified.

Inventory the error-producing components in scope
Start by listing every component in the system boundary that can return an error to a user, an administrator or another service. Include web front ends, APIs, authentication services, database connections, batch jobs, reverse proxies and the self-hosted platforms themselves. The system owner and platform engineers should build this list from the architecture diagram and the system security plan, then confirm it against running configurations. The step is complete when each component has an owner and a documented error behavior to review. That inventory also tells you which components the SI-11 evidence must cover.
Define which roles may see which error detail
SI-11 requires the organization to define the personnel or roles who may receive detailed error information, and this decision fills the organization-defined parameter in the control. Typically the security team, platform operators and application owners need fuller detail than end users, but the boundary should be set by your own risk decisions. Record the roles, the detail each may see and the approver. The output is a short, approved table that appears in the system security plan. Ask any assessor you work with how they expect the parameter to be written before you finalize it.
Set user-facing and privileged error formats
Define two message formats: a generic message for end users that says what happened and what to do next, such as retrying or contacting support with a reference code, and a richer message for defined roles that carries the information needed for corrective action. Neither format may expose stack traces, internal host names, database schemas, file paths, credentials or software versions to users outside the defined roles. Write the templates in the form each component supports and keep them under version control. The output is a template set per component type, each reviewed against the inventory from the first step.
Centralize error handling and disable debug output in production
Route errors through a common handler where the framework allows it, rather than letting each module format its own output. Confirm that debug modes, verbose tracebacks and development error pages are disabled in production configurations, and that production deployments are built from a configuration file reviewed as part of change control. Check the default error pages of web servers, proxies and application frameworks, because many ship with detailed output enabled. The output is a production configuration baseline and a record showing that debug settings were checked on each component.
Route full error detail to protected logs
Detailed error information still needs to exist for corrective action, so send it to a log destination that only defined roles can read. Where the platform supports audit logging, confirm which error events it records, where the log file is written and who holds read access. For example, Nextcloud's admin_audit app writes additional event information to audit.log in the data directory or a path set with logfile_audit, and OpenBao's audit devices record API errors as JSON with most sensitive values hashed. Verify each product's logging behavior in its own documentation. The output is a log configuration with restricted permissions and a sample record from each component.
Test the error paths
Trigger errors deliberately to confirm that each path returns the correct user-facing message, that no sensitive detail appears in the response, and that the full record reaches the protected log. Cover invalid input, failed authentication, missing resources, dependency outages and forced exceptions in each component from the inventory. Automated tests can check response bodies for stack trace markers or internal identifiers. The output is a test script or test record with pass and fail results, and any defects logged to the change process with an owner and a retest. Keep the results so the assessor can see the behavior, not only the design.
Document the configuration as assessment evidence
Bring the decisions and results together in a package that maps to the SI-11 assessment. This covers the defined roles and parameter, the message templates, the production configuration baseline, the log access settings, the test results and the procedure for reviewing error handling after changes. The SP 800-53A assessment procedure for SI-11 examines documentation of error message structure and content, system design documentation, configuration settings and audit records, so each of these should exist in the package. Store the package with the system security plan and set a review trigger for significant changes. Your implementation partner can prepare this package, but the organization owns the control and an independent assessor determines whether it is met.

Which SI-11 evidence passes an assessment and how to keep it current

An assessor testing SI-11 looks for documents that define what error messages say, configuration that proves detailed output is off in production, and logs that show errors are recorded for administrators. Each artifact below goes stale as code and settings change, so the refresh step matters as much as the first capture.

Error message structure and content document

This document defines what a user sees when something fails: a generic message, a correlation or reference code, and the corrective guidance the control requires. It should list which fields may appear in each message class and which never may, such as stack traces, query text, hostnames, file paths and credentials. Assessors read it against the SI-11 examine objects. Refresh it whenever a new error type or front-end form is added, and tie the review to the pull request template so new endpoints must declare their messages.

Defined roles and the organization-defined parameter

SI-11 has one organization-defined parameter that names the personnel or roles allowed to see detailed error information. The assessor checks that the value is written down, approved and matches the access granted in the system. Confirm the exact wording against the release 5.2.0 catalog in your own environment. Refresh the parameter at the same interval as your access reviews, and reconcile it with the group memberships that can read detailed logs.

Production configuration exports with debug output off

Exported settings from production show that debug modes, verbose error pages and stack trace rendering are disabled. Capture them from the running environment, not from the repository, because drift between the two is a common finding. Store each export with a timestamp and a hash so changes are visible. Refresh by scheduling a configuration comparison against the approved baseline and by running the same check after every deployment to production.

Sample error responses from test runs

Captured responses from negative tests, such as malformed requests, expired sessions and forced exceptions, show what an outside party actually receives. Keep a short set of these, each paired with the test case that produced it. Assessors use them to confirm that messages give corrective information without leaking internals. Refresh them by running the same negative test suite in the release pipeline and archiving the responses for each build that changes an error path.

Access control lists for error and audit logs

Error logs and audit logs often hold the detail that the user-facing message must withhold, so their read permissions are part of SI-11. Export the access control lists for the log locations and the identity groups bound to them, and confirm that only the defined roles can read them. Refresh the export at each access review and whenever log storage, a log shipper or a dashboard integration is added.

Audit records showing errors are logged in detail

The control expects errors to be captured for administrators even though users see little. Sample audit records that show timestamp, component, error class, and the request context needed for diagnosis, drawn from both normal and failed operations. Confirm that the logging component records what the platform produces, and check that your log settings still write the events you claim. Refresh with a scheduled sample taken from production logs each review cycle, and after any logging library upgrade.

What meeting SI-11 costs in money and effort

This table compares the cost components of meeting SI-11 Error handling, showing who does the work, whether each cost is one-time or recurring, what pushes it up or down and what to request in a quote. NIST does not estimate compliance costs, so no figures appear here; use the drivers to scope and compare quotes.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Engineering time to refactor error handling	One-time, with recurring change work	Up: number of applications, legacy code paths, many inconsistent error responses. Down: a central error handler that all services already call.	Named list of applications and error paths in scope, with the change method for each
Configuration and environment hardening	One-time, then recurring on upgrades	Up: many web servers, frameworks and debug settings per environment. Down: one configuration baseline applied through code.	Settings checked per environment, such as debug mode and verbose error pages, and how drift is detected
Log access controls for error records	One-time setup, recurring access reviews	Up: error logs holding sensitive values spread across tools. Down: an existing logging platform with role-based access.	Who can read error logs, how access is granted and reviewed, and where sensitive values are masked
Testing of error paths	Recurring with each release	Up: many input types and failure modes, third-party components that fail differently. Down: automated tests in the existing pipeline.	Test cases covering invalid input, dependency failure and forced exceptions, and the pass criteria
Evidence upkeep	Recurring	Up: frequent releases, many systems, manual screenshots. Down: configuration and test results stored automatically with dates.	Evidence list mapped to the assessment objects for SI-11, and retention period for each item
External penetration testing or code review of error paths	Recurring, per test cycle	Up: broad attack surface, many public endpoints, unfamiliar frameworks. Down: a narrow, well-defined scope agreed in writing.	Whether error responses, stack traces and verbose errors are in the written test scope and in the report
Auditor sampling and assessor time	Recurring, per assessment cycle	Up: many systems to sample, unclear evidence ownership. Down: one owner per evidence item and a documented error message standard.	Assessor requirements for sampled systems, evidence format and the number of samples the assessor expects

Who owns SI-11 and what is worth outsourcing

Your organization owns SI-11. Accountability sits with the system owner and the security function, and the decisions that define the control are yours to make and to sign. These decisions shape every later step, so they should not be delegated to a vendor or a partner.

Parameter value: SI-11 has one organization-defined parameter in Release 5.2.0. Your team sets the value that defines which personnel or roles may see detailed error information.
Error policy approval: Leadership or the authorizing official approves the rules for what users, administrators and logs may see when something fails.
Log review: Your staff reviews the audit records that capture errors and confirms that detailed messages are not reaching unauthorized viewers.
Role assignment: Your team maintains the list of who can view detailed diagnostics and removes access when people change roles.
Ongoing ownership: Changes to applications, frameworks and error pages go through your change process, so each new release is checked against the policy.

Before engaging anyone, confirm that a named owner can explain the approved error policy and point to the people who can see detailed error output.

Self-hosted open-source tools that support SI-11 evidence

Three open-source tools in the supplied facts can produce pieces of SI-11 evidence, though none of them is a complete answer on its own. GitLab Community Edition, licensed under MIT, supports change evidence. Its protected branches let maintainers restrict which roles can push or merge changes, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Applied to the repository that holds error-handling configuration, such as web server error page templates, framework debug settings or API error serializers, these settings give an assessor a reviewable history of who approved each change to what users and administrators see when something fails. Confirm that your own branch rules and approval workflow match the change process you describe in your system documentation.

Semgrep Community Edition, licensed under LGPL-2.1-only, can help catch error responses that expose internals before they reach production. It scans code in languages including Java, Python, JavaScript, TypeScript, Go, C#, PHP and Ruby, and it accepts custom rules, so your team can write patterns that flag stack trace output, exception objects returned to clients or database error text placed in responses. Running these rules in CI/CD pipelines gives repeatable scan results that can serve as examination evidence. Confirm that the languages and frameworks in your stack are covered by the community rules or by rules you write, because a clean scan only reflects the patterns you have defined.

Nextcloud's admin_audit app, licensed under AGPL-3.0-only, and OpenBao, licensed under MPL-2.0, provide the logging side of the evidence. The admin_audit app logs additional event information to audit.log in the data directory, or to a path set with logfile_audit, which can show administrative actions taken in response to errors. OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. That error record is useful for showing that failures are captured for administrators while secrets stay out of plain text. Confirm with your own testing whether these logs contain the detail your assessor expects, and check that error logs are protected from the users who generate them.

What buyers ask about SI-11 cost, time and effort

How much effort does SI-11 take for an existing application?

The effort depends mainly on how many error paths the application already has and how many of them expose detail to users. SI-11 is a single base control with one organization-defined parameter and no enhancements, so the requirement itself is small. The work usually sits in code review and testing: finding where stack traces, SQL errors, file paths, library versions, credentials or internal hostnames reach a response body, a log that users can read, or a support screen. An application with a centralized error handler is far quicker to bring into line than one where each module formats its own messages. Confirm with your assessor which error-message documentation and configuration evidence they expect before you size the work.

Does a moderate system need SI-11 separately from SI-2 and SI-15?

Yes. SI-11 is assigned to the moderate and high baselines in its own right, so it must be assessed as its own control even though it is related to SI-2 (flaw remediation) and SI-15 (information output filtering). The related-control listing in the Release 5.2.0 catalog connects SI-11 to AU-2, AU-3, SC-31, SI-2 and SI-15, which tells you where evidence may overlap, not that one control satisfies another. Audit records from AU-2 and AU-3 can show how errors are logged, and SI-15 output filtering can address some leakage paths. Map each control's evidence separately in your system security plan and confirm the overlap approach with your assessor.

What does the work need from the internal team?

The internal team needs people who can name the error-handling behavior of each component and who can make decisions about what users and administrators should see. In practice that means developers who own the application code, an operations engineer who knows the logging pipeline and who can read audit records, and a security owner who defines the personnel or roles allowed to see detailed error information. Someone also has to keep the documented structure and content of error messages current as the system changes. Those roles are needed whether an outside partner helps or not, because the organization owns its controls and the decisions behind them.

Can our team implement SI-11 without outside help?

A capable internal team can usually do this without outside help, particularly for a single application with a standard framework and a clear logging setup. Outside help tends to add value when many systems share legacy code, when error handling is spread across several technologies, or when the team lacks time to run structured testing of error paths. An implementation partner can prepare systems, configuration and evidence, and can run tests you define. Only an independent assessor or auditor evaluates the control and reports on it. Ask any partner to state in writing which parts they will do and which parts remain with your staff.

How do timelines depend on the number of components and legacy code?

Timelines grow with the number of components that return errors to users or write them to logs, and with how much of that code is legacy. Each separate service, API, batch job, admin console and third-party integration needs its own review, because each may format errors differently. Legacy code adds time when error handling is inconsistent, when messages are hard-coded in many places, or when no tests cover failure paths. A small, well-tested application with one error handler is a very different job from a dozen services maintained by different teams. Ask for the timeline to be broken down by component and by whether each one needs code change, configuration change or evidence collection only.

What should a scoping conversation cover for SI-11?

A scoping conversation should settle which systems fall within the authorization boundary, which components produce user-facing or log-facing errors, and which roles may see detailed error information. It should also confirm the assessment objects your assessor will examine, such as error-message documentation, system design documentation, configuration settings and audit records. Agree on the testing you will perform, who fixes defects, and who signs off. Ask the provider to put the scope, deliverables, evidence list and exclusions in writing before work starts, since most engagements are fixed-scope and the written scope drives the quote.

What recurring effort should we expect after SI-11 is in place?

After the first pass, the recurring effort is mostly change control. Each new feature, dependency upgrade or logging change can reintroduce detailed errors, so error-path tests should run in the normal release pipeline and the error-message documentation should be updated with the system. Reviewers must also check audit logs for stored error content, and access to those logs should follow the defined roles. Budget for this as ongoing operational work owned by your teams, and confirm with your assessor how often they expect to see evidence of review.

How DeployOpen scopes and prepares SI-11 evidence

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, so error handling for SI-11 is settled in the systems that actually generate the messages. We prepare the configuration and evidence for the assessment, while the organization owns the control and an independent assessor reviews it.

How we scope

We agree a written scope listing which applications, APIs and platforms in your environment return user-facing and administrator-facing errors.
We record who the organization defines as authorized recipients of detailed error information, since SI-11 turns on that defined set of personnel or roles.
We confirm the organization-defined parameter for SI-11 and the audit log locations that will hold error events before any work begins.

How we build

We configure platforms so user-facing errors show corrective guidance without stack traces, credentials, file paths or internal hostnames.
We route detailed error and debug output to restricted logs, and we check the audit settings of tools such as Nextcloud's admin_audit app and OpenBao audit devices.
We test error responses with negative test cases and record the results for the examine and test methods in SP 800-53A.

How we hand over

We deliver configuration documentation describing the structure and content of error messages, plus system design notes for error flows.
We provide the configuration settings, test records and sample audit records that an assessor would examine for SI-11.
We walk your control owners through the evidence so they can explain it to the independent assessor, who makes the final determination.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so error handling stays correct after platform updates.
We re-test error responses after material changes to platforms, plugins or logging configuration, and we update the evidence set to match.
Confirm with your assessor which evidence format and retention period they expect before we finalize the handover package.

SI-11 Error handling