Error Handling

To meet the FedRAMP Moderate error handling requirement, your systems must produce error messages that help teams fix problems without exposing details an attacker could exploit, and those detailed errors must be visible only to defined roles (for example, administrators or support). Operationally, this means separating user-facing errors from internal diagnostic data and enforcing role-based access to logs and error details. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Error messages must be “actionable” for correction but “safe” against information leakage. (NIST Special Publication 800-53 Revision 5)
• Separate external errors (generic) from internal diagnostics (detailed), and restrict who can see the detailed view. (NIST Special Publication 800-53 Revision 5)
• You need documented roles, technical controls, and evidence that the pattern is implemented across apps, APIs, and infrastructure. (NIST Special Publication 800-53 Revision 5)

“Error handling requirement” sounds like an application concern, but for FedRAMP it is a control requirement that auditors will test across the stack: UI, APIs, identity flows, logging pipelines, and incident response. SI-11 expects two outcomes: (1) the system generates error content that supports corrective action, and (2) error content does not leak exploitable information and is only revealed to approved personnel or roles. (NIST Special Publication 800-53 Revision 5)

For a CCO or GRC lead, the fastest path to operationalizing SI-11 is to treat it as an engineering standard plus an access-control requirement. You will need (a) rules for what can appear in user-facing errors, (b) a mechanism to capture rich diagnostics securely, (c) role definitions and enforcement (RBAC/ABAC) for who can see those diagnostics, and (d) evidence that the standard is implemented and monitored.

This page gives requirement-level implementation guidance: who it applies to, what to build, how to test it, what artifacts to retain, and where teams usually fail in audits.

Regulatory text

Requirement (SI-11): “Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited; and reveal error messages only to organization-defined personnel or roles.” (NIST Special Publication 800-53 Revision 5)

Operator interpretation (what you must do):

1. Design error outputs so they are useful for remediation (for example, a trace ID, timestamp, and high-level failure category) without exposing sensitive internals (stack traces, config values, precise authorization logic, database schema, secrets, or account enumeration signals). (NIST Special Publication 800-53 Revision 5)
2. Restrict visibility of detailed errors (the “why” and “how” diagnostics) to defined roles (for example, SRE/on-call, security, system administrators, tier-2 support). “Defined roles” must exist in writing and be enforced technically. (NIST Special Publication 800-53 Revision 5)

Plain-English requirement: what “good” looks like

A compliant pattern is two-channel error handling:

• External channel (user/API client): short, consistent messages that don’t disclose internals. Includes a correlation/trace ID so support can find the underlying event.
• Internal channel (logs/observability): rich diagnostics (exception details, stack trace, dependency responses) stored in secured systems where access is limited to approved roles.

The goal is to prevent information disclosure while keeping operations effective. SI-11 is not asking you to hide failures; it is asking you to control the content and the audience of failure information. (NIST Special Publication 800-53 Revision 5)

Who it applies to (entity + operational context)

Entities

• Cloud Service Providers operating systems in a FedRAMP Moderate authorization boundary. (NIST Special Publication 800-53 Revision 5)
• Federal Agencies operating or inheriting cloud services and enterprise applications subject to FedRAMP Moderate controls. (NIST Special Publication 800-53 Revision 5)

Operational contexts where SI-11 is commonly tested

• Web applications and portals (authentication, registration, profile management)
• APIs (REST/GraphQL), especially auth and authorization failures
• Batch processing jobs and data pipelines
• Administrative consoles and privileged tooling
• Identity and access flows (SSO errors, MFA failures)
• Logging/monitoring platforms (SIEM, APM, centralized logging) and who can access them

What you actually need to do (step-by-step)

1) Define your “safe error” standard (policy + engineering rules)

Create a short, enforceable standard that answers:

• What user-facing errors may contain: generic reason category, timestamp, request ID/trace ID, and a support instruction.
• What user-facing errors must not contain: stack traces, code paths, library versions, hostnames, internal IPs, database errors, object IDs tied to other users, credentials, tokens, secrets, or any message that confirms whether a username/email exists.
• Approved error taxonomy: standard error codes (for example: AUTH-001, PAY-003, DEP-002) that map to internal runbooks.

This is where GRC adds value: make it unambiguous so engineering can implement it consistently and audit can test it consistently. The requirement is about avoiding “information that could be exploited” and restricting error visibility by role. (NIST Special Publication 800-53 Revision 5)

2) Separate presentation from diagnostics (technical design pattern)

Implement a consistent pattern across services:

User-facing response

• HTTP status or UI state
• Generic message (no internals)
• Correlation ID

Internal capture

• Full exception/stack trace
• Dependency context (downstream status, timeouts)
• Security-relevant context (request principal, authorization outcome)
• Sanitized payload fragments only if required, and only in secure logs

Practical implementation mechanisms:

• Central error-handling middleware
• Exception filters/interceptors
• API gateway standard error mapping
• “No stack trace in production responses” configuration for frameworks where applicable

3) Control who can see detailed errors (RBAC + tooling)

SI-11 explicitly requires error messages be revealed only to organization-defined roles. Implement this in the systems where diagnostics live: (NIST Special Publication 800-53 Revision 5)

• Central logging platform access controls (RBAC groups aligned to roles)
• Ticketing system permissions if errors are copied into incidents
• On-call dashboards access controls
• Break-glass access process for emergency visibility

Define the roles in writing (examples):

• System Administrator / SRE: full diagnostic visibility
• Security Operations: diagnostic visibility plus audit trails
• Tier-1 Support: correlation ID lookup and limited metadata, no stack traces
• Developers: scoped visibility to services they own, with approval workflow for cross-service access

4) Add guardrails to prevent accidental leakage

Common guardrails that auditors like because they are testable:

• Automated tests that confirm production responses never include stack traces or sensitive fields
• Static analysis checks for banned error patterns (for example, printing raw exception messages to clients)
• Log scrubbing/redaction rules for secrets and personal data
• Standardized “unknown error” behavior that still yields a correlation ID

5) Validate with negative testing (prove what users cannot see)

Build a small test script or checklist that intentionally triggers:

• Invalid login (ensure no account enumeration)
• Authorization failure (ensure it doesn’t describe permission model)
• Database constraint violation (ensure DB error not returned)
• 500 exceptions (ensure generic message, correlation ID returned)
• Input validation errors (safe, minimal field-level info)

Your evidence should show that external consumers get safe messages while internal teams can retrieve the detailed diagnostic using the correlation ID. (NIST Special Publication 800-53 Revision 5)

6) Operationalize: monitoring and incident workflows

Operationally, error handling ties to incident response and support:

• Runbooks must reference correlation IDs and log search steps
• Support scripts must avoid asking users to screenshot raw errors if those screens could include sensitive details
• Severity classification should consider whether an error message leak occurred (that becomes a security event)

7) Extend to third party and shared responsibility boundaries

If a third party runs part of your stack (managed database, SaaS logging, outsourced support), ensure contracts and access controls preserve SI-11 intent:

• Third party support staff access to logs must be role-based and approved
• Data shared in tickets must be sanitized
• Federated access must be auditable

If you use Daydream to manage third-party risk and due diligence, map your logging/observability providers and outsourced support teams as third parties and collect evidence of their RBAC controls and support processes that limit error visibility to authorized roles. This closes a common gap where the app is compliant but the support workflow leaks details. (NIST Special Publication 800-53 Revision 5)

Required evidence and artifacts to retain

Auditors typically want proof that the requirement is designed, implemented, and operating. Keep:

Governance artifacts

• Error Handling Standard (what’s allowed/prohibited in external errors)
• Role definitions and access policy for diagnostic systems (who can see what)
• Secure logging and retention guidance tied to your boundary

Technical artifacts

• Architecture diagram showing error flow: client → service → logging/APM → access controls
• Configuration snapshots showing production error detail disabled in responses
• Sample redacted and non-redacted error outputs (before/after or prod vs internal)
• Automated test results (CI logs) validating no sensitive error leakage
• Logging platform RBAC export (groups/roles), plus audit logs showing access reviews

Operational artifacts

• Runbooks that use correlation IDs to locate internal diagnostics
• Incident/ticket examples showing safe customer messaging and separate internal detail
• Evidence of periodic access review for log systems and support tooling

Common exam/audit questions and hangups

Expect these lines of inquiry:

1. “Show me a production error.” They will trigger failures and inspect the response for stack traces, hostnames, or user enumeration signals. (NIST Special Publication 800-53 Revision 5)
2. “How does support troubleshoot with generic errors?” You must show correlation IDs and internal lookup workflows. (NIST Special Publication 800-53 Revision 5)
3. “Who can access logs and APM?” They will ask for role definitions and RBAC evidence, not just “admins only.” (NIST Special Publication 800-53 Revision 5)
4. “How do you prevent developers from logging secrets?” You need guardrails: redaction, code review standards, scanning, and detection.
5. “Does this apply to third parties?” If third parties can see detailed errors through support channels or observability tooling, you need controls and evidence.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails SI-11	Fix
Returning raw exception messages to API clients	Leaks exploitable internals	Centralize error mapping; replace with generic message + correlation ID (NIST Special Publication 800-53 Revision 5)
Disabling stack traces in UI but leaving them in API responses	Partial implementation	Standardize across web, API, mobile, and integrations
“Everyone in engineering can see prod logs”	Errors revealed beyond defined roles	Enforce RBAC; define roles; use least privilege and approvals (NIST Special Publication 800-53 Revision 5)
Support tickets include screenshots/log dumps with sensitive internals	Errors revealed outside approved roles	Train support; sanitize templates; restrict ticket visibility
Logging sensitive payloads “for debugging”	Creates new exposure and audit findings	Redact by default; log minimal fields; controlled debug flags with approvals

Risk implications (why auditors care)

Error messages are a common path to unintended disclosure: they can reveal system structure, security controls, and user/account existence. SI-11 forces discipline: safe external outputs and controlled internal visibility. When this control is weak, the impact is not limited to a single application bug; it often becomes a systemic weakness across services and support workflows. (NIST Special Publication 800-53 Revision 5)

Practical execution plan (30/60/90 days)

First 30 days: establish the standard and find the worst exposure

• Publish a one-page error handling standard and prohibited content list. (NIST Special Publication 800-53 Revision 5)
• Identify all user-facing entry points (apps, APIs, admin tools).
• Run negative tests to find stack traces, verbose auth errors, and DB error leakage.
• Inventory where detailed errors live (logs/APM/tickets) and who can access them.

By 60 days: implement the pattern across priority services

• Add centralized error-handling middleware and correlation IDs.
• Configure frameworks to suppress detailed production errors to clients.
• Implement RBAC in logging/APM and align groups to documented roles. (NIST Special Publication 800-53 Revision 5)
• Update support workflows: correlation ID intake, no raw dumps to broad ticket audiences.

By 90 days: prove it operates and stays compliant

• Add CI tests and code review checks for error leakage.
• Implement log redaction rules and validate they work with sample events.
• Perform an access review for diagnostic systems; record approvals and removals.
• Assemble an audit packet: standard, role definitions, test results, RBAC evidence, and example incident showing correlation ID workflow.

Frequently Asked Questions

Do we have to hide all error details from end users?

No. SI-11 requires errors provide information needed for corrective action without revealing exploitable details, and detailed errors must only be visible to defined roles. Use generic messages plus a correlation ID for users, and keep rich diagnostics internal. (NIST Special Publication 800-53 Revision 5)

What counts as “information that could be exploited”?

Treat stack traces, dependency versions, internal hostnames/IPs, database error strings, and account enumeration clues as exploitable by default. If the message helps an attacker understand your internals more than it helps a legitimate user recover, move it to internal diagnostics. (NIST Special Publication 800-53 Revision 5)

How do we reconcile this with troubleshooting needs for support and engineering?

Use correlation IDs and secure internal logs so support can look up detailed diagnostics without exposing them to the user. Pair this with runbooks and RBAC so only approved roles can retrieve the details. (NIST Special Publication 800-53 Revision 5)

Does SI-11 apply to logs, or only to on-screen/API error messages?

It applies to “error messages” broadly, and auditors commonly test both what the user sees and what internal tooling reveals to different roles. Treat logs and observability platforms as part of the control boundary for “revealing” error messages. (NIST Special Publication 800-53 Revision 5)

What should we show an auditor as proof?

Provide your error handling standard, role definitions, RBAC configuration for logging/APM, test evidence that external errors are sanitized, and a walkthrough showing correlation ID lookup by an authorized role. (NIST Special Publication 800-53 Revision 5)

Our third party support provider needs access to logs. Is that allowed?

Yes, if they are included in your organization-defined roles (or mapped to them), access is least-privilege, and activity is auditable. Keep ticket content sanitized and limit what’s shared outside secured diagnostic systems. (NIST Special Publication 800-53 Revision 5)