Network Security Policy

Version: 1.0 · Status: Active · Effective: 2026-05-05

1. Purpose

This policy describes the network security controls that Projan AI Ltd (company number 17196385) maintains to protect customer data and application workloads. It covers the architectural principles, isolation boundaries, traffic controls, and monitoring practices that govern all network infrastructure supporting the Projan platform.

2. Scope

This policy applies to all cloud network infrastructure across Projan’s development, testing, and production environments. It covers virtual private cloud architecture, subnet design, load balancing, traffic encryption, egress controls, and infrastructure recovery mechanisms.

All infrastructure is defined and deployed using Infrastructure as Code (IaC), ensuring that network configurations are version-controlled, auditable, and reproducible.

3. Network Architecture

Each environment operates within a dedicated virtual private cloud (VPC) hosted in the EU (London) region. This ensures that all customer data remains within the United Kingdom and is subject to UK data protection law.

Every VPC is divided into two distinct subnet tiers:

Public subnets host only internet-facing load balancers and network address translation (NAT) resources. No application workloads run in public subnets.
Private subnets host all application services, including API servers, messaging gateways, and background workers. These subnets have no direct inbound route from the internet.

Each environment spans multiple availability zones to provide resilience against localised infrastructure failures. DNS resolution is enabled within all VPCs to support internal service discovery.

Outbound internet access from private subnets is provided through a managed NAT layer in the public subnet tier, ensuring that application workloads can reach required external services while remaining unreachable from the public internet.

4. Environment Isolation

Projan enforces strict environment isolation through account-level separation. Each environment - development, testing, and production - is deployed into its own dedicated cloud account. This provides hard isolation boundaries at the identity, network, and resource level:

Identity isolation: Each account maintains its own access policies. Credentials and roles in one environment cannot access resources in another.
Network isolation: Each environment has its own VPC with a unique address space. No VPC peering exists between environments, meaning there is no network path between development, testing, and production workloads.
Secrets isolation: Sensitive credentials (database URIs, API keys, encryption keys) are stored per-account in a managed secrets service. Task execution roles are scoped to access only secrets within their own environment.
Resource isolation: Compute, storage, and database resources are provisioned independently per environment. A misconfiguration or incident in one environment cannot propagate to another.

A separate shared-services account manages DNS zones and cross-account configuration references, but holds no application data or workloads.

5. Traffic Controls

All inbound traffic to Projan services passes through application load balancers (ALBs) deployed in public subnets. Direct access to application containers is not possible from the internet.

Traffic flow is controlled through security groups that enforce the principle of least privilege:

Load balancer security groups permit inbound traffic only on HTTP and HTTPS ports from the public internet. All other ports and protocols are denied by default.
Service security groups permit inbound traffic only from the load balancer security group on the application port. No other inbound traffic is accepted.
NAT security groups permit traffic only from within the VPC address space to support outbound connectivity for private subnets.

All security group rules are defined in code and subject to change control. Rules are audited quarterly to verify that no unnecessary access has been introduced.

6. TLS and Certificate Management

All traffic between clients and Projan services is encrypted in transit using TLS. The following controls are in place:

TLS termination occurs at the load balancer. All HTTPS listeners use certificates issued by a managed certificate authority.
Automatic HTTP-to-HTTPS redirect: Any request arriving on port 80 receives a permanent redirect (HTTP 301) to the HTTPS endpoint. No application traffic is served over unencrypted HTTP.
DNS-validated certificates: All TLS certificates are validated via DNS records, eliminating the need for manual validation processes.
Automatic renewal: Certificates are automatically renewed before expiry. No manual intervention is required for certificate lifecycle management.
Environment-specific certificates: Each environment uses its own certificate with appropriate subject alternative names for all service subdomains within that environment.

Each environment follows a consistent domain naming convention that separates API, application, and messaging gateway endpoints under environment-specific subdomains.

7. Egress Controls

Application services require outbound connectivity to a defined set of external services:

Database services - managed database cluster connectivity
AI inference APIs - model providers for AI-powered features
Payment processing - Stripe for subscription and billing operations
Messaging platforms - Slack for bot messaging and workspace integration
Project management APIs - Jira and Notion for integration ticket and document sync
Email delivery - transactional email provider for account notifications
Cloud platform APIs - identity management, object storage, secrets retrieval, container registry, and logging services

Outbound traffic from private subnets routes through a NAT layer with a fixed IP address, which is used for IP-based allowlisting on external services that require it (such as the database cluster).

All outbound traffic is currently permitted at the security group level. Projan is evaluating network-level egress filtering to restrict outbound connections to known destination endpoints as an additional defence-in-depth measure.

8. Monitoring and Recovery

Projan implements automated monitoring and recovery controls across all environments:

Health checks: Load balancers perform periodic health checks against each application service. Unhealthy instances are automatically removed from the target group and replaced.
NAT layer recovery: The NAT infrastructure is monitored for system-level failures. Automated recovery restarts the NAT layer without manual intervention if a failure is detected.
Circuit breaker deployments: Application deployments use a circuit breaker pattern. If a new deployment fails health checks, the platform automatically rolls back to the last known healthy version.
Deregistration draining: When instances are removed from service (during deployments or scaling events), in-flight requests are allowed to complete before the instance is terminated.

Infrastructure monitoring is integrated with the cloud platform’s native alerting services to ensure prompt notification and response.

9. Review Schedule

Activity	Frequency	Responsible
Full policy review and update	Annually, or after significant infrastructure changes	Director
Security group rule audit	Quarterly	Director
Certificate renewal verification	Continuous (automated)	Automated
NAT infrastructure patching	Monthly (automated updates enabled)	Automated
Cross-account access review	Annually	Director
Egress control assessment	Annually	Director

10. Contact

For questions about this policy or to report a network security concern, contact the Projan security team:

Email: security@projan.ai

Projan AI Ltd will acknowledge all security-related enquiries within 5 business days.

Policies