Skip to content

SC.04 — Vulnerability and Patch Management#

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

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

Control Attestation Table#

Control Description Status Evidence
CTRL0537503 (SC.04.01) Define which parts of the IT system require patching Compliant vulnerability-patch-management.md section 1 (Scope)
CTRL0537512 (SC.04.02) Define a process for routine assessment and patching Compliant vulnerability-patch-management.md section 2 (Vulnerability Assessment Process)
CTRL0537499 (SC.04.03) Perform routine assessment and patching Compliant vulnerability-patch-management.md section 3 (Patch Frequency and Ownership)
CTRL0537514 (SC.04.06) Urgent vulnerabilities must always be patched Compliant vulnerability-patch-management.md section 4 (Urgency and Severity Handling)
CTRL0537483 (SC.04.09) Decide which components must be monitored Compliant vulnerability-patch-management.md section 3 (Patch Frequency and Ownership)
CTRL0537520 (SC.04.10) Evaluate security patches on a risk basis Compliant vulnerability-patch-management.md section 4 (Urgency and Severity Handling)
CTRL0537498 (SC.04.11) Implement relevant patches at a defined frequency Compliant vulnerability-patch-management.md section 5 (Testing Before Deployment)
CTRL0537522 (SC.04.16) The processes for routine assessment must be documented Compliant vulnerability-patch-management.md sections 6 (Patch Evidence Log) & 7 (Deviations)

Security Controls Reference#

CTRL0537503 — SC.04.01: Define which parts of the IT system require patching#

Control Text: Define which parts of the IT Solution should be regularly assessed for vulnerabilities.

Applicability: Basic IT security requirement.

Additional Description

The first step in vulnerability management is determining which parts of the IT solution need to be assessed or scanned. Consider, for example:

  • Is it relevant to scan the operating system, or only the application layer?
  • Are only certain parts of the application in scope?
  • If the solution is on the CORP network, some parts may be automatically updated by Global IT Operations (GITO) — for more information see the IT Hub article on centralised IT security updates.

Detailed Description

The AI Connectors platform fulfils this control by maintaining a documented scope definition that identifies all technology stack components requiring vulnerability assessment. The scope covers six component categories (Docker base images, Python dependencies, nn-mcp-core library, Infrastructure-as-Code, GitHub Actions, and AWS managed services) with explicit ownership assignments distinguishing between AI Connectors team-managed components and externally-managed services. This clear delineation ensures vulnerability management efforts focus on components where the team has direct remediation authority while maintaining visibility into external dependencies.

Implementation Considerations

CTRL0537512 — SC.04.02: Define a process for routine assessment and patching#

Control Text: Define a process for routine assessment and remediation, mitigation or risk acceptance of vulnerabilities on the IT Solution.

Applicability: The IT Solution is not on CORP or PSNet, or not using centrally managed patching.

Additional Description

All IT solutions should ensure processes are in place (via scanning or assessment) to identify vulnerabilities across the solution. In addition, local processes should be established to keep track of published vulnerabilities for critical components, for example by monitoring news feeds from relevant vendors and communities.

If the IT solution is placed on CORP or PSNet networks, the vulnerability assessment service offering described in the IT Hub may be relevant.

Detailed Description

The AI Connectors platform fulfils this control through a multi-layered vulnerability assessment process combining automated scanning (Snyk CI/CD integration, GitHub Advanced Security, AWS account-level scanning) with manual monitoring of vendor security advisories. Snyk executes SAST, SCA, container, and IaC scanning on every pull request with results uploaded to GitHub Security for mandatory review before merge. All findings are triaged weekly with high/critical vulnerabilities triggering immediate patching and medium/low issues batched into routine cycles, ensuring vulnerabilities are detected through multiple channels and remediated following a risk-based prioritization model.

Implementation Considerations

CTRL0537499 — SC.04.03: Perform routine assessment and patching#

Control Text: Perform routine assessment and remediation, mitigation or risk acceptance of vulnerabilities on the IT Solution.

Applicability: The IT Solution is not on CORP or PSNet, or not using centrally managed patching.

Additional Description

When vulnerabilities are identified, assess the urgency and criticality of each and decide on appropriate action. Typically, appropriate action involves:

  • Configuration changes
  • Implementation of patches
  • Acceptance of non-critical vulnerabilities (must be anchored in a risk assessment of the vulnerability in the context of the IT solution)

Detailed Description

The AI Connectors platform fulfils this control by executing routine patching according to component-specific cadences with severity-driven escalation. Docker and Python components are assessed monthly with immediate action for Critical/High CVEs, Terraform and GitHub Actions quarterly, and AWS managed services continuously via AWS automatic patching. All patches flow through dev environment testing before production deployment, and vulnerabilities that cannot be immediately remediated due to breaking changes or missing vendor fixes are documented in the deviations table with justification and target dates.

Implementation Considerations

CTRL0537514 — SC.04.06: Urgent vulnerabilities must always be patched#

Control Text: Urgent vulnerabilities must always be addressed as soon as possible after formal notification from DD&IT or Global Security Operations (GSO).

Applicability: Basic IT security requirement.

Additional Description

IT solutions should always be updated and patched as soon as possible when critical vulnerabilities are discovered. The expected response time and process should be defined as part of the control implementation (e.g. in the Operations & Maintenance document).

GITO and Global Security Operations (GSO) will publish formal notifications for critical vulnerabilities.

If the IT solution is delivered by a third-party vendor, a formal process must exist for the vendor to notify IT system owners/managers or Product Owners in Novo Nordisk. The notification contact and response time should be regulated in the contract between Novo Nordisk and the vendor.

Detailed Description

The AI Connectors platform fulfils this control by implementing CVSS-based response time targets that map vulnerability severity to patching deadlines: Critical (≥9.0 CVSS) within 48 hours, High (7.0–8.9) within 7 days, Medium (4.0–6.9) within 30 days, and Low (<4.0) within 90 days. The platform monitors multiple notification channels including Global Security Operations, AWS Security Hub, GitHub Security, and vendor advisories to ensure rapid awareness. Even emergency patches follow the dev-test-prod pipeline with Production environment gate approval, maintaining change control while enabling expedited critical vulnerability response, and rollback capability is preserved through ECS task definition revision management.

Implementation Considerations

CTRL0537483 — SC.04.09: Decide which components must be monitored#

Control Text: Unless otherwise decided by the CISO, decide which components must be part of a patch management process, and decide on the patch process, including frequency.

Applicability: Basic IT security requirement.

Additional Description

Establish a foundation for integrating patching into maintenance processes per component, covering:

  • Responsibility: Who is responsible for patch evaluation (e.g. IT solution manager, vendor, Global IT)?
  • Frequency: How often are patches evaluated (e.g. monthly, quarterly, yearly)?
  • Approach: How are patches applied (e.g. via release process, ad-hoc/emergency, infrastructure releases)?

If the solution is on the CORP network, some parts may be automatically updated by GITO. For more information, see the IT Hub article on centralised IT security updates and the Security Patch Management - Client PCs and Windows Servers - Guideline on the IT&Q Portal.

Detailed Description

The AI Connectors platform fulfils this control through a component-level governance model that assigns clear ownership (AI Connectors team for Docker/Python/Terraform/GitHub Actions, AWS for managed services, GitHub for runners), defines risk-aligned patching frequencies (monthly for Docker/Python, quarterly for Terraform/Actions, continuous for AWS), and establishes layer-appropriate implementation approaches (application-layer via standard CI/CD, infrastructure-layer via Terragrunt, emergency via hotfix with expedited approval). All patches are tested in dev before prod deployment with no cross-environment promotion without explicit approval, ensuring every component has a clear owner, assessment cadence, and patching mechanism.

Implementation Considerations

CTRL0537520 — SC.04.10: Evaluate security patches on a risk basis#

Control Text: Evaluate security patches on a regular basis and decide if they are relevant for the IT Solution and if they need to be approved by an IT supplier (for instance the IT Solution provider) before being implemented.

Applicability: Basic IT security requirement.

Additional Description

In accordance with the patch governance defined for the IT solution, patches should be evaluated as part of ongoing maintenance. The purpose is to identify and understand the benefits and risks associated with implementing a given patch.

IT solutions that are not security patched in a timely manner according to vendor recommendations should be effectively isolated from computer networks and the internet, where relevant.

If the solution is on the CORP network, some parts may be automatically updated by GITO. Refer to the Security Patch Management - Client PCs and Windows Servers - Guideline and the Database Security Patch Management Guidelines on the IT&Q Portal.

Detailed Description

The AI Connectors platform fulfils this control by evaluating patches using a multi-criteria risk model that considers CVSS scores, exploitability status, attack vector, impact potential, and vendor recommendations. Patches are reviewed weekly during security triage meetings where findings from Snyk, Dependabot, AWS Security Hub, and vendor advisories are assessed and prioritized according to severity-driven timelines (Critical/High with exploitation triggers 48-168 hour response, Medium follows 30-day cycles, Low deferred to quarterly). Patches introducing breaking changes are documented in the deviations log with justification and target dates, and all decisions are made internally by the AI Connectors team without third-party supplier approval requirements.

Implementation Considerations

CTRL0537498 — SC.04.11: Implement relevant patches at a defined frequency#

Control Text: Implement relevant patches at the earliest convenient time. Before implementing the patch, assess or test the compatibility to avoid adverse impact on the business processes.

Applicability: Basic IT security requirement.

Additional Description

To reduce the risk of security vulnerabilities and ensure the solution remains up-to-date, implement relevant patches as soon as possible after they become available.

Before implementing a patch:

  • Test compatibility on a lower environment (e.g. dev or test) to identify potential issues.
  • Ensure patch implementation is included in the change management process.
  • Have a rollback plan in place in case of adverse impact.

If the solution is on the CORP network, some parts may be automatically updated by GITO. Refer to the Security Patch Management - Client PCs and Windows Servers - Guideline and the Database Security Patch Management Guidelines on the IT&Q Portal.

Detailed Description

The AI Connectors platform fulfils this control by implementing all patches through an eight-stage pipeline that mandates dev environment testing before production deployment regardless of severity. The pipeline includes lint checks, Snyk scanning to confirm CVE resolution, automatic dev deployment upon merge, automated smoke tests, health checks, manual verification for Critical patches, and Production environment gate approval before prod deployment. Rollback capability is maintained through ECS task definition revision management and ECR image retention with sub-5-minute recovery time, and all patches are tracked as GitHub issues following the emergency change process for urgent vulnerabilities.

Implementation Considerations

CTRL0537522 — SC.04.16: The processes for routine assessment must be documented#

Control Text: The processes for routine assessment and remediation, mitigation or risk acceptance of vulnerabilities on the IT solution and its components must include an assessment of vendor recommendations for timely deployment of changes. List of IT solution's components (incl. servers) in scope of potential patching and list of patches deployed must be maintained or producible on demand. If a patch has not been deployed in due time, the reason must be documented.

Applicability: Basic IT security requirement. Applies to components managed outside of central patch management processes.

Additional Description

The vulnerability management process must take supplier advisories and recommended deployment timelines into account.

Deviations from supplier recommendations are acceptable when supported by adequate risk-based justification. Justification can be made at the level of a single vulnerability or as a policy choice in the vulnerability management process. The key is demonstrating that deviations are deliberate, risk-informed decisions — not gaps in the security program.

Maintain a record of patches/changes applied per component (patch ID, dates, owner, test/rollback notes). For cloud solutions, include these requirements in vendor contracts and require vendors to produce patch evidence on demand.

Detailed Description

The AI Connectors platform fulfils this control by maintaining centralized documentation that covers scope definition, assessment mechanisms, patch frequencies, urgency handling, and testing procedures alongside evidence logs for patches applied and deviations from vendor recommendations. The patch evidence log captures date, component, version change, CVEs addressed, testing confirmation, and deployment status, while the deviations log documents deferred patches with risk-based justification, risk acceptor, and target dates. Vendor advisories are reviewed weekly during security triage meetings and factored into response time targets, and all documentation (component lists, patch history, scan results) is producible on demand through the vulnerability-patch-management document, GitHub commit history, GitHub Security tab, and AWS Security Hub.

Implementation Considerations