Skip to content

Authorization Boundary Diagram for FedRAMP

An Authorization Boundary Diagram (ABD) is a visual representation of your system's software components, data flows, and security boundaries. It shows how data moves between internal and external systems, which ports and protocols are used, and where components reside within the Game Warden environment, ensuring your system connects securely with the platform and satisfies all deployment and security requirements.

As the most critical visual component of the System Security Plan (SSP), the ABD serves as the definitive boundary of what is in scope for the authorization. It defines precisely what is within scope when the Authorizing Official (AO) grants FedRAMP Authorization to your organization.

Understanding data flow and external connections

As part of preparing your ABD, it’s important to illustrate how data moves in and out of your system. This helps ensure your application integrates smoothly with Game Warden and meets the security expectations required for deployment.

We look for three types of data flow in your diagram:

  • Ingress – When data enters your system (e.g., user input or file uploads).
  • Egress – When data exits your system (e.g., sending logs or API responses).
  • Bidirectional – When data flows both ways (e.g., interactions with third-party APIs).

Clearly marking these flows makes it easier for our team to assess how your system interacts with other services. See External Data Connections Overview for security considerations and best practices.

Authorization Boundary Diagram requirements

How you create your ABD depends on your authorization path. Game Warden supports two models:

  • In-boundary (Accelerated Authorization) - Your application deploys within the Game Warden FedRAMP authorization boundary. Game Warden's existing ATO covers your platform and infrastructure layer, and your ABD reflects your application as a component within that boundary.
  • Out-of-boundary (Traditional Certification Path) - Your application pursues its own FedRAMP ATO through an Agency Sponsor. You retain full ownership of your authorization package, and your ABD must depict Game Warden as an external, leveraged service outside your boundary.

The tabs below cover the ABD requirements for each model.

Your FedRAMP submissions must adhere to NIST 800-53 standards and FedRAMP Authorization Boundary Guidance, and must include the following details:

1. Boundary and component representation Your diagram must delineate the shared responsibility model and categorize every component:
  • Shared responsibility: Distinguish between platform-managed (inherited) components, customer-managed application components, and external systems.
  • External authorizations: For each external system interconnection, identify whether the system is FedRAMP-authorized or non-authorized. For non-authorized systems, indicate whether the connection is initiated by your application or the external system. Non-authorized external systems must not process, store, or transmit federal data unless explicitly approved.
  • Operational services: Show where alternate processing sites are located and how updates (e.g., operating system patches, antivirus definitions) are obtained from external services.
2. Data flow and encryption Your diagram must show how federal data moves through your system and how it is secured at every stage:
  • Federal data locations: Identify all locations where federal data is transmitted, processed, or stored, and indicate which components handle the data at each stage.
  • Encryption protections: For every data flow and data store, identify the protective mechanisms in place. For Data in Transit (DIT) and Data at Rest (DAR), indicate the encryption status and call out where FIPS 140-validated cryptographic modules are used.
3. System inventory validation Your diagram must serve as a visual representation of your written inventory:
  • Exact label matching: Component labels in your diagram must match the corresponding entries in the "Diagram Label" column of your FedRAMP Integrated Inventory Workbook.
  • Internal component consistency: Every internal component listed in your inventory must appear in your diagram, and every major component in your diagram must be accounted for in the inventory.
4. Sub-diagrams (if architecture is separated) If your architecture is complex, you may separate it into multiple diagrams. All sub-diagrams must use consistent naming conventions, color coding, and legends:
  • Network diagram: Include sub-networks, network zones, trust boundaries, and the locations of DNS authoritative and recursive servers.
  • Data Flow Diagram: Represent user types (e.g., privileged, non-privileged, agency customers), MFA usage, ports and protocols, and DAR/DIT protective mechanisms.
5. The narrative description Every diagram submitted for FedRAMP must be accompanied by a written narrative that serves as the authoritative explanation of your system. The narrative must align with your diagram and inventory, and must include:
  • System overview: The system's purpose, supported business functions, and operating environment.
  • User access and authentication: How different user types interact with the system and how access is enforced.
  • Step-by-step data flow: A walkthrough of how federal data enters, traverses, and exits the system.
  • Security mechanisms: DIT/DAR encryption, FIPS validation, network protections, and logging mechanisms.
  • External interconnections: The nature of connections to external systems and how those interactions are secured.

You must still adhere to standard FedRAMP diagram requirements, such as identifying data flows, FIPS 140-validated encryption, and system inventories, but you must depict Game Warden differently in your diagram than an in-boundary customer would.

When creating your ABD for your own Third-Party Assessment Organization (3PAO) and AO, incorporate the following:

1. Game Warden as a leveraged service Your boundary surrounds your application and organizational components. Depict Game Warden outside your authorization boundary and label it as a Leveraged FedRAMP-Authorized Service. Because Game Warden implements the FedRAMP High baseline, it can support systems categorized at the High, Moderate, or Low impact levels — document which applies to your system in your SSP.
2. Clear control delineation Your diagram must visually distinguish the shared responsibility model by separating:
  • Customer responsibility: Your application code, services, application-layer IAM, and organizational components.
  • Inherited responsibility: The platform and infrastructure layer managed by Second Front.
Note: Your 3PAO will focus their assessment on your boundary definition, control allocation, and customer-implemented controls. Second Front's authorization already validates the Game Warden platform controls.

Example diagrams

The following examples illustrate how an ABD should be structured for each authorization path. Use these as a reference when building your own diagram.

FedRAMP Auth Boundary Diagram

Tip

Need help with creating your diagram or have questions about your architecture? Reach out to your Mission Success Manager (MSM).