Skip to content

SC.10 — IT Recovery#

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

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

Control Attestation Table#

Control Description Status Evidence
CTRL0537500 — SC.10.01.01 Determine adequate backup policy Compliant Backup policy documented in backup-disaster-recovery.md and operation-maintenance.md section 4.9; RPO and RTO objectives defined per component
CTRL0537484 — SC.10.01.02 The backup process must be verified Compliant Recovery testing schedule documented in operation-maintenance.md section 4.9: quarterly ECS redeploy drills, annual DynamoDB PITR restore tests, annual full environment rebuild
CTRL0537476 — SC.10.02 Ensure that backups have sufficient retention Compliant DynamoDB backups use AWS-managed PITR (continuous, 35-day retention); S3 audit logs use versioning with lifecycle policies (90d Standard → 365d Glacier); Terraform state retained indefinitely; physical security provided by AWS infrastructure
CTRL0537492 — SC.10.03.01 Ensure that an IT recovery plan exists Compliant IT recovery plan documented in operation-maintenance.md section 4.9 and backup-disaster-recovery.md; recovery procedures defined per failure scenario with RTO targets
CTRL0537480 — SC.10.03.02 Test the IT recovery plan on a periodic basis Compliant Recovery testing schedule established in operation-maintenance.md section 4.9: quarterly ECS redeploy drills (dev), annual DynamoDB restore tests (dev), annual full environment rebuild (isolated workspace), annual secret rotation drills (dev); test evidence retained in project issue tracker

Security Controls Reference#

CTRL0537500 — SC.10.01.01: Determine adequate backup policy#

Control Text: Determine adequate backup processes of IT solution and data, reflecting the business requirements including RPO or agreed supplier metrics (KPIs), the security requirements and criticality of the information.

Applicability: Basic IT security requirement.

Additional Description

Understand the criticality of data and IT solutions by collaborating with business stakeholders to determine acceptable data loss (RPO — Recovery Point Objective). RPO refers to the maximum amount of data that can be lost from the point of a critical event to the most preceding backup. As a general rule: the smaller the RPO, the higher the cost of the solution.

Key steps: - If backups are managed by an external supplier, establish KPIs reflecting backup objectives within SLAs and regularly review supplier performance. - Document and communicate clear backup objectives that support business continuity requirements. - Choose appropriate backup methods (full, incremental, or differential) based on data volume and frequency of changes.

For more information, see "Manage backup and recovery of IT systems - Guideline" on the Manage Backup and Recovery section of the IT&Q Portal.

Detailed Description

The AI Connectors platform implements component-specific backup policies tailored to the criticality and replaceability of each data type. Because the platform operates as a stateless proxy that does not store business data, the backup strategy focuses on operational state, audit logs, and infrastructure configuration, with documented RPO and RTO targets per component. Critical components like audit logs and Terraform state have zero data loss tolerance (RPO=0) and are protected by S3 versioning and deletion policies, while ephemeral components like the DynamoDB token cache can be regenerated on demand. This layered approach ensures critical configuration and audit data are protected, while ephemeral operational state can be quickly regenerated to meet RTO targets between 15 minutes (ECS service) and 1 hour (full environment rebuild).

Implementation Considerations

CTRL0537484 — SC.10.01.02: The backup process must be verified#

Control Text: The backup process must be tested on a regular basis to verify data integrity and availability. Evidence must be retained for verification.

Applicability: Basic IT security requirement.

Additional Description

Conduct routine tests of the backup process to confirm that data can be accurately restored and is available when needed. Keep records of these tests, including: - Dates of tests - Issues found during tests - Corrective actions taken

This evidence demonstrates the backup process's effectiveness and reliability.

For more information, see "Manage backup and recovery of IT systems - Guideline" on the Manage Backup and Recovery section of the IT&Q Portal.

Detailed Description

The AI Connectors platform conducts regular recovery testing to verify that each component can be restored within its documented RTO and that recovery procedures are accurate and complete. Testing is performed on a structured schedule covering different failure scenarios: quarterly ECS redeploy drills (most common failure mode), annual DynamoDB PITR restore tests (validates backup mechanism), annual full environment rebuilds (end-to-end catastrophic loss scenario), and annual secret rotation drills (credential compromise). All tests are documented with dates, issues found, corrective actions, and time-to-recovery measurements, with evidence retained for 3 years in the team's SharePoint folder and recovery documentation updated after each debrief.

Implementation Considerations

CTRL0537476 — SC.10.02: Ensure that backups have sufficient retention#

Control Text: Ensure that backups have a sufficient level of physical security.

Applicability: Basic IT security requirement.

Additional Description

The information stored in a backup is just as critical to protect as the IT solution itself, and should be subject to similar physical security controls. Special consideration should be given to backups of critical information — ensure the backup is physically located in a separate location from the primary system.

For guidance on physical security controls, see the SC.11 — Physical and environmental security guidance page.

Detailed Description

The AI Connectors platform relies entirely on AWS-managed cloud storage for backups, inheriting AWS's physical data center security controls rather than managing physical media directly. All backup storage services (S3, DynamoDB PITR, SSM Parameter Store) are hosted in the AWS eu-central-1 region, which is certified to SOC 2 Type II and ISO 27001, with physical security including 24/7 surveillance, multi-factor access controls, environmental controls, and redundant power systems. The platform implements logical controls (SSE-S3 encryption, versioning, deletion policies, IAM restrictions) on top of AWS's physical infrastructure, with backup storage architecturally separated from application components to ensure a failure or compromise of the ECS service does not affect audit archives or Terraform state. The AWS Shared Responsibility Model divides responsibilities: AWS handles physical security of infrastructure, while the AI Connectors team manages logical access controls, encryption configuration, and backup policy enforcement.

Implementation Considerations

CTRL0537492 — SC.10.03.01: Ensure that an IT recovery plan exists#

Control Text: Ensure that an IT recovery plan is developed and maintained, identifying and describing how to restore the IT solution and data in alignment with the business recovery objectives, restoration priorities, and other metrics (e.g. RTO or MTD).

Applicability: Basic IT security requirement.

Additional Description

Create an IT recovery plan detailing the steps to recover systems and data after an incident. The plan should: - Align with the IT Solution's overall business continuity requirements - Include specific recovery objectives and priorities (e.g. RTO — Recovery Time Objective, the maximum tolerable downtime after a failure) - Be regularly reviewed and updated to reflect changes in the IT environment and business needs

As a general rule: the shorter the RTO, the higher the cost of the solution needed to achieve it.

For more information, see "Manage backup and recovery of IT systems - Guideline" on the Manage Backup and Recovery section of the IT&Q Portal.

Detailed Description

The AI Connectors platform maintains a comprehensive IT recovery plan organized by failure scenario, allowing the on-call team to quickly locate the relevant runbook based on the nature of the incident. The plan covers five primary scenarios: ECS service failure (RTO 5–30 minutes), SSM secret compromise (RTO 15–30 minutes), DynamoDB table loss (RTO 5–30 minutes), full environment loss (RTO 1–2 hours), and Terraform state loss (RTO 4–8 hours). Each recovery procedure includes specific RTO targets, prerequisites, detailed commands, verification criteria, and rollback instructions, with RTO targets aligned to business requirements that prioritize development agility and cost-efficiency over extreme availability since the platform is a stateless proxy with no business data storage.

Implementation Considerations

CTRL0537480 — SC.10.03.02: Test the IT recovery plan on a periodic basis#

Control Text: Test the IT recovery plan on a regular basis and retain the evidence for verification.

Applicability: Basic IT security requirement.

Additional Description

Establish a schedule for regular testing of the IT recovery plan. Key steps:

  • Develop a variety of test scenarios simulating different types of disruptions (minor technical issues through to major disaster).
  • Coordinate with all relevant stakeholders to ensure comprehensive testing and clarity of roles.
  • During the test, document any issues and evaluate the effectiveness of the recovery procedures.
  • After the test, hold a debriefing session to identify weaknesses and update the recovery plan accordingly.
  • Maintain detailed records of each test (scenarios, participants, outcomes, plan updates) and store this evidence securely for audit purposes.

Detailed Description

The AI Connectors platform tests its IT recovery plan on a regular schedule using scenarios that cover different failure types and severities: quarterly ECS redeploy drills (most common failure), annual DynamoDB PITR restore tests, annual full environment rebuilds (catastrophic loss), and annual secret rotation drills (credential compromise). Testing is performed in the development environment or isolated workspaces to avoid production impact, with each test following a structured protocol of pre-test preparation, runbook execution, verification against pass criteria, and post-test debrief. All test execution is documented with dates, participants, issues, corrective actions, and time-to-recovery measurements, with evidence retained for 3 years in SharePoint and recovery documentation updated after each debrief to reflect lessons learned.

Implementation Considerations