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 and identifies the ports and protocols for each connection, and where components locate 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

Your ABD must show how data moves into and out of your system. This enables the Game Warden team to verify your integration and security requirements for deployment.

Include the following three types of data flow in your diagram:

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

Marking these flows makes it easier for the 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 Certification) - 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 certification through an Agency Sponsor. You maintain ownership of your certification 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-certified or non-certified. For non-certified systems, indicate whether the connection is initiated by your application or the external system. Non-certified 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 (for example, 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 identify where FIPS 140-validated cryptographic modules protect the data.
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 (for example, 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.

In-boundary FedRAMP Requirements

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-certified or non-certified. For non-certified systems, indicate whether the connection is initiated by your application or the external system. Non-certified 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 (for example, 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 identify where FIPS 140-validated cryptographic modules protect the data.
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 (for example, 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.

Out-of-Boundary FedRAMP Requirements

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-Certified Service. Because Game Warden implements the FedRAMP Class D baseline, it can support systems categorized at Class D, Class C, or Class B Certification Classes - 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 certification already validates the 2F Platform controls.

Export your ABD as a high-resolution PNG

Open the ABD template in Excalidraw by selecting Open or dragging the file into the editor. Export the completed ABD as a high-resolution PNG, regardless of certification path, so reviewers can read all text, including IP addresses, ports, and protocols, when zooming in. Select Export image, choose PNG, and set the scale to the largest available option.

→ Download ABD template

Example diagrams

The following examples show how to structure an ABD for each certification path. Use these as a reference when building your own diagram.

FedRAMP Auth Boundary Diagram

Tip

Need support with creating your diagram or have questions about your architecture? Reach out to your Mission Success Manager.