Network and Infrastructure Security Policy template (SOC 2)

1. Purpose

Northwind runs on infrastructure that Northwind Cloud Inc configures but does not physically own. This policy sets how that infrastructure is designed, segmented, hardened, changed and watched, so that only intended traffic reaches production, administrative access is tightly controlled, and weaknesses are found and fixed before they are exploited.

2. Scope

This policy applies to every network, subnet, load balancer, firewall rule, DNS zone, compute instance, container platform, managed database, storage bucket, queue and edge service that hosts or supports Northwind, in production, staging and development. Northwind Cloud Inc currently hosts on AWS and Vercel. It also covers any office network or corporate VPN that Northwind Cloud Inc operates, and the infrastructure-as-code held in GitHub and deployed through GitHub Actions. Endpoints and provider data centres are covered by the Endpoint and Workstation Security Policy and the Physical and Remote Work Security Policy respectively.

3. Roles and Responsibilities

• Executive Management approves the infrastructure budget and this policy, and formally accepts residual risk where a control cannot be met; Priya Natarajan, CEO is the approver of record.
• Security Owner (Dana Whitfield, CTO) approves the network architecture and hardening baselines, reviews the firewall and access reviews, owns external testing and handles escalated anomalies.
• Engineering owns this policy through the Engineering Lead, operates the infrastructure, writes and reviews infrastructure-as-code, applies hardening baselines, responds to alerts and performs the reviews in Section 5.
• People Operations ensures that infrastructure administrators are onboarded and offboarded under the Human Resources Security Policy and that administrator role changes reach Engineering the same day.
• All Personnel with infrastructure access use only the approved paths in this policy and report suspected misconfigurations or unauthorised access to security@northwindcloud.example.

4. Policy Statements

• 4.1 Production, staging and development environments are isolated in separate accounts, projects or subscriptions with no shared network paths, credentials or data. Production data is not copied into non-production environments except as anonymised or synthetic datasets approved by the Security Owner.
• 4.2 Every environment follows a segmented network design, applied on each hosting platform Northwind Cloud Inc uses as follows:
• AWS: workloads sit in private subnets or equivalent private segments with no direct inbound route from the internet; databases and caches accept connections only from application segments; security groups and firewall rules default to deny and allow only documented ports and sources; and a web application firewall or equivalent edge protection fronts every public HTTP endpoint.
• Vercel: workloads sit in private subnets or equivalent private segments with no direct inbound route from the internet; databases and caches accept connections only from application segments; security groups and firewall rules default to deny and allow only documented ports and sources; and a web application firewall or equivalent edge protection fronts every public HTTP endpoint.
• 4.3 Data stores are never exposed to the public internet. Storage buckets default to private, public access is blocked at the account level, and any intentional public bucket or endpoint is documented and approved by the Security Owner.
• 4.4 All traffic to and between Northwind services is encrypted in transit with TLS 1.2 or higher, using certificates from a trusted authority with automated renewal. Plaintext protocols are not permitted across any network boundary.
• 4.5 Administrative access is granted only to named individuals through single sign-on from Okta with multi-factor authentication, following least privilege under the Access Control Policy. Root or owner credentials are protected by hardware multi-factor authentication and used only for logged, reviewed break-glass scenarios.
• 4.6 Interactive access to servers and containers goes through the provider's session management service, an identity-aware proxy or a session-recording bastion. Inbound SSH and RDP from the internet are prohibited, and short-lived credentials replace static access keys wherever the platform supports them.
• 4.7 Infrastructure is defined as code in GitHub, changed only through peer-reviewed pull requests and deployed through GitHub Actions under the Change Management Policy. Manual console changes to production are limited to emergencies, are logged and are reconciled into code within five business days.
• 4.8 Every compute image, container base image and managed service is configured against a documented hardening baseline informed by provider best practices and CIS benchmarks: unnecessary services disabled, default credentials removed, instance metadata access restricted and logging enabled.
• 4.9 Secrets (API keys, database passwords, signing keys, tokens) live in the platform's secret manager and are injected at runtime. They are never committed to GitHub, baked into images or written to logs, and are rotated on a defined schedule and immediately after any suspected exposure.
• 4.10 Network flow logs, load balancer logs, DNS query logs and cloud audit logs are enabled in every environment and retained in Datadog under the Logging and Monitoring Policy. Alerts fire on security group changes, new public exposures, root or owner account use and unusual outbound traffic.
• 4.11 Public-facing services are protected against denial-of-service and abusive traffic by the provider's DDoS protection and edge rate limiting. Production workloads span at least two availability zones or equivalent failure domains.
• 4.12 Northwind Cloud Inc operates as a Remote organisation and treats no office or home network as trusted. Access depends on the identity and device of the person connecting, not on the network, and any corporate VPN is limited to specific administrative destinations.
• 4.13 The external attack surface of Northwind is scanned for open ports, exposed services and known vulnerabilities at least monthly, and an independent penetration test of production is performed at least annually and after major architectural changes. Findings are remediated under the Vulnerability and Patch Management Policy.

5. Procedures

• 5.1 Network change. Any change to a firewall rule, security group, route, load balancer or DNS record is proposed as a pull request in GitHub, reviewed by a second engineer for least privilege and unintended exposure, and applied through GitHub Actions. Emergency console changes are announced in the incident channel and reconciled into code within five business days. Owner: Engineering. Timing: every change.
• 5.2 Quarterly rule and exposure review. Each quarter Engineering exports every rule permitting inbound traffic from the internet, plus all public IP addresses, buckets and endpoints, and reviews them with the Security Owner. Rules without documented justification are removed within ten business days; the export, notes and removal tickets are retained as evidence. Owner: Engineering Lead. Cadence: quarterly.
• 5.3 Administrator access review. Each quarter the Security Owner reviews the identities holding administrative roles on AWS and Vercel, confirms that each belongs to current personnel with a business need and has multi-factor authentication enforced, removes unjustified access and reviews any break-glass use. Owner: Security Owner. Cadence: quarterly.
• 5.4 Hardening baseline. Engineering maintains the hardening baseline and validates new images against it in GitHub Actions before promotion to production. Drift found by configuration scanning is corrected within 30 days, or 7 days for internet-facing components. Owner: Engineering Lead. Cadence: reviewed annually; validated on every build.
• 5.5 Certificate and secret management. TLS certificates renew automatically, and expiry alerts fire 21 days before any certificate that cannot auto-renew expires. Each secret has a recorded owner and a rotation schedule of at most 12 months for static credentials, and the secrets inventory is reviewed quarterly. Owner: Engineering. Cadence: continuous; quarterly inventory review.
• 5.6 External scanning and penetration testing. Engineering scans all public endpoints at least monthly and triages results within five business days. The Security Owner engages an independent penetration testing firm annually, tracks findings to closure in the vulnerability register and retains the report and remediation evidence. Owner: Security Owner. Cadence: monthly scan; annual test.
• 5.7 Monitoring and response. Alerts from Section 4.10 route from Datadog to the on-call engineer, who acknowledges within 30 minutes in business hours and two hours otherwise, and either closes the alert with a note or opens an incident under the Incident Response Policy. Alert rules are tuned quarterly. Owner: Engineering. Cadence: continuous; tuning quarterly.
• 5.8 Architecture review. The Engineering Lead maintains a network and architecture diagram showing environments, segments, ingress points, data stores and trust boundaries, updates it whenever a new environment, service or ingress point is introduced, and walks the Security Owner through it annually, recording accepted deviations from Section 4.2 as exceptions. Owner: Engineering Lead. Cadence: Annual and on material change.

6. Exceptions

Exceptions must be requested in writing to the Security Owner with the business reason and the compensating controls, and approved by Priya Natarajan, CEO. Approved exceptions are recorded in the exception register with an expiry date no more than 12 months away and are reviewed at each quarterly rule review. No exception may permit a data store to be reachable directly from the internet.

7. Enforcement

Infrastructure that presents an active exposure may be isolated or shut down by Engineering without notice. Personnel who bypass network controls or make undocumented production changes are subject to disciplinary action under the Human Resources Security Policy, up to and including termination.

8. Review Cadence

The Engineering Lead and the Security Owner review this policy on a annual basis and whenever a hosting platform or environment is added or the architecture changes materially. Reviews are recorded in Section 9 and changes communicated to everyone with infrastructure access within 30 days.

9. Revision History