Security Architecture
Network boundaries, production networks, customer integration paths, VPN access, security groups, firewalls, and WAF-equivalent controls restrict traffic to approved paths.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Only approved traffic paths can reach production, data, and administrative services, and each permitted route has a current business purpose and accountable owner.
First SOC 2 program
Draw the actual ingress, egress, administration, integration, and database paths; keep data services private; use deny-by-default security groups; protect public applications through managed edge controls; and use a controlled remote-administration path.
As the company scales
Separate workloads into risk zones, manage rules as code, restrict egress and transitive connectivity, collect flow events, and run recurring owner reviews that remove stale or overly broad paths.
Document sources, destinations, ports, protocols, trust zones, administrative routes, customer integrations, and internet exposure for each production service and data store.
You should end up with: A current network-flow diagram plus a path inventory with owners and purposes.
Separate public entry points, application workloads, data services, management paths, and shared services, then define the minimum connections allowed between them.
You should end up with: A zone model and approved connectivity matrix that reviewers can compare with deployed rules.
Use specific sources, destinations, identities, ports, and protocols; keep management and database interfaces private; and prevent direct origin access that bypasses edge protections.
You should end up with: Firewall, security-group, routing, edge, and remote-access configurations implementing the approved paths.
Review proposed rule and routing changes for purpose, scope, testing, and rollback, then preserve the change decision and deployed difference.
You should end up with: Network change records linked to reviewed configuration changes.
Compare deployed rules with the connectivity matrix, investigate unexpected flows, remove unused or expired rules, and document any risk-accepted path.
You should end up with: A boundary review with rule ownership, traffic observations, removals, and resolved exceptions.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
The reviewed design shows current trust zones, ingress, egress, administration, data-service, customer integration, peering, and edge-to-origin paths with accountable owners.
Include this context
Environment and zones
Include this context
Sources and destinations
Include this context
Ports or protocols
Include this context
Edge and origin path
Include this context
Private and peer connections
Include this context
Owner and review date
Weak evidence to avoid
A cloud icon diagram with no route direction, ports, management path, peering, origin exposure, environment, or review date.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
An accountable reviewer compared diagrams and approved connectivity with current firewall, routing, peering, remote-access, and observed-flow state, resolving stale or excessive paths.
Include this context
Review scope and date
Include this context
Current rule population
Include this context
Reviewer
Include this context
Unexpected or stale path
Include this context
Decision or exception
Include this context
Removal and verification
Weak evidence to avoid
A calendar entry for a firewall review with no rule population, diagram comparison, findings, exception decisions, or verified removals.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The current deployed state restricts each network path to the approved source, destination, port, protocol, and resource scope at a stated time.
Include this context
Rule ID
Include this context
Source and destination
Include this context
Port and protocol
Include this context
Affected resource
Include this context
Rule purpose or owner
Include this context
Generated-at timestamp
Weak evidence to avoid
A screenshot of one allow rule without inherited rules, affected resources, routing context, owner, purpose, or export time.
Confirm what the record proves
The current remote-administration path limits authenticated users, devices, routes, session conditions, and target networks according to the approved design.
Include this context
VPN or access service
Include this context
Authorized group
Include this context
Authentication requirement
Include this context
Permitted routes
Include this context
Session or device condition
Include this context
Generated-at timestamp
Weak evidence to avoid
A login page proving the VPN exists but not who may connect, which routes it exposes, whether strong authentication applies, or what is currently configured.
Confirm what the record proves
Each network rule, route, peering, VPN, or edge change has a defined purpose, authorization, test, deployed difference, and rollback path.
Include this context
Change ID
Include this context
Affected path or rule
Include this context
Reason and owner
Include this context
Approval timestamp
Include this context
Deployed change and time
Include this context
Test and rollback result
Weak evidence to avoid
A closed ticket saying ‘opened port’ without the source, destination, rule ID, approver, deployment event, validation, or rollback information.
Type 1
As of the selected date, retain the current reviewed network diagram, current firewall, security-group, routing, peering, edge, and remote-access configurations, and the latest boundary review with completed remediation or explicit exceptions.
Type 2
Include every firewall, security-group, route, peering, VPN, zero-trust access, edge, origin-exposure, and material egress change during the review period; each required boundary review and its full current-rule population; and every resulting removal, correction, or approved exception.
Reconcile cloud and network-device configuration histories, infrastructure deployments, and direct console events to approved changes; then reconcile current rules and routes to the reviewed diagram, observed traffic, and exception register.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Only approved traffic paths can reach production, data, and administrative services, and each permitted route has a current business purpose and accountable owner.
Compare the documented owner with the intended role (Infrastructure / Security Operations / IT), then compare dated records with the stated cadence: Continuous/ongoing; periodic review by risk.
Reconcile cloud and network-device configuration histories, infrastructure deployments, and direct console events to approved changes; then reconcile current rules and routes to the reviewed diagram, observed traffic, and exception register.
As of the selected date, retain the current reviewed network diagram, current firewall, security-group, routing, peering, edge, and remote-access configurations, and the latest boundary review with completed remediation or explicit exceptions.
Include every firewall, security-group, route, peering, VPN, zero-trust access, edge, origin-exposure, and material egress change during the review period; each required boundary review and its full current-rule population; and every resulting removal, correction, or approved exception.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates The reviewed design shows current trust zones, ingress, egress, administration, data-service, customer integration, peering, and edge-to-origin paths with accountable owners.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates An accountable reviewer compared diagrams and approved connectivity with current firewall, routing, peering, remote-access, and observed-flow state, resolving stale or excessive paths.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates The current deployed state restricts each network path to the approved source, destination, port, protocol, and resource scope at a stated time.
For each selected record, confirm it demonstrates The current remote-administration path limits authenticated users, devices, routes, session conditions, and target networks according to the approved design.
For each selected record, confirm it demonstrates Each network rule, route, peering, VPN, or edge change has a defined purpose, authorization, test, deployed difference, and rollback path.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.