Skip to content

SC.02 — Network Security and Architecture#

System: AI Connectors Platform Last updated: 2026-04-29

This document describes how the AI Connectors platform fulfils the SC.02 control category.

Control Attestation Table#

Control Description Status Evidence
CTRL0537486 — SC.02.01 Design or use networks with adequate controls Compliant AWS VPC architecture with security groups, ALB with TLS termination, private subnets for ECS tasks
CTRL0537511 — SC.02.02 Ensure that the implemented network controls are effective Compliant AWS-managed infrastructure with SLAs, CloudWatch monitoring, Terraform-managed configuration
CTRL0537526 — SC.02.04 Separate environments (production / non-production) Compliant Separate AWS accounts for dev (094069622854) and prod (673034950531), distinct VPCs and network boundaries

Security Controls Reference#

CTRL0537486 — SC.02.01: Design or use networks with adequate controls#

Control Text: Design or use networks which adequately protect data and segregate solutions in scope of this risk assessment. Implement and maintain sufficiently segregated network architecture by use of network security controls such as firewall technology, proxies, IPS, etc. under the requirements set by the Novo Nordisk Network Security Standard.

Applicability: The IT Solution is connected to a network.

Additional Description

Novo Nordisk segregates and differentiates between Novo Nordisk networks and non-Novo Nordisk networks. Between those two, a centrally operated firewall device should be placed.

The internal network is to be configured and operated based on best practice principles. Internal segregation is in most cases mandated by isolating systems not meeting Novo Nordisk General network standards (patching, non-GISP operating systems, etc.).

The NN Network Security Standard (located in the Network Security Toolbox) specifies how to design and operate a network according to a set of security principles. Security controls such as IPS and IDS are technologies used to inspect traffic and stop malicious activity.

An effective intrusion detection and prevention system should be implemented on systems facing the internet in order to monitor the network for successful or unsuccessful intrusion attempts from external parties.

Detailed Description

The platform fulfils this control through a defense-in-depth network architecture built on AWS-managed services. All MCP containers run in private subnets with no direct internet access, protected by security groups that only permit inbound traffic from the Application Load Balancer. The ALB enforces TLS 1.2+ encryption for all external connections and routes traffic to backend services based on subdomain. Outbound connectivity to Azure AD and Microsoft Graph is controlled via NAT Gateways, while AWS DynamoDB and S3 are accessed through private VPC endpoints. This layered approach ensures that application workloads are isolated from direct internet exposure and that all data in transit is encrypted, fulfilling the network segregation and encryption requirements of the NN Network Security Standard.

Implementation Considerations

CTRL0537511 — SC.02.02: Ensure that the implemented network controls are effective#

Control Text: Ensure that the implemented network security controls are managed and maintained according to agreed best practice and anchored in relevant operational agreements or SLAs.

Applicability: The IT Solution is connected to a network.

Additional Description

The NN Network Security requirements (located in the Network Security Toolbox) specify how to design and operate a network according to a set of security principles.

To assure that all security-related network components are well functioning and that changes are under control, it is advised to use a central monitoring system that:

  • Tracks the status of these controls at all times
  • Ensures all changes to these controls are authorised and documented

Due to the criticality and impact that a malfunctioning or End-of-Life network security device could cause, it is important to have a clear picture of the SLA/contracts that components should live up to.

Detailed Description

The platform fulfils this control by relying exclusively on AWS-managed network services with formal SLAs (ALB 99.99% uptime, NAT Gateway 99.5%), eliminating the need for custom network devices or end-of-life hardware. All network configuration is defined as infrastructure-as-code in Terraform, version-controlled, and subject to code review and automated CI/CD workflows that enforce change control and peer approval. Continuous monitoring through AWS CloudWatch, Security Hub, and GuardDuty provides real-time visibility into network security posture and operational health, with per-MCP alarms for authentication failures, error rates, and service availability.

Implementation Considerations

CTRL0537526 — SC.02.04: Separate environments (production / non-production)#

Control Text: Separate environments (production, development, test, validation, sandboxes) physically, logically, or in time.

Applicability: Basic IT security requirement.

Additional Description

The main objective of environment separation is to ensure that production environments are reliable and that patients always have access to their medicines.

From an information security perspective, environment separation:

  • Protects the availability and stability of production by ensuring configuration and application changes are first tested in development/sandbox environments
  • Restricts the number of user accesses to production
  • Reduces the risk of accidental or malicious changes to live systems

At least one non-production environment (such as a validation environment) should have configuration and security controls identical to the production environment. The separation can be achieved through dedicated hardware, virtualised environments, or time-based promotion (an environment is promoted to production and can no longer be used for validation). Once an environment is in production, all security controls must be applied and followed.

Detailed Description

The platform fulfils this control through complete physical and logical separation of dev and prod environments using dedicated AWS accounts with zero shared infrastructure or network connectivity. Development workloads run in account 094069622854, production in account 673034950531, each with separate VPCs, ECS clusters, DynamoDB tables, SSM secrets, and Azure AD app registrations. The dev environment mirrors production architecture identically, ensuring that all security controls, network configurations, and authentication flows are validated before production deployment. Container images are built once, tested in dev, then promoted to production via a GitHub Actions approval gate that requires explicit manual authorization before any code reaches the production environment.

Implementation Considerations