SIAS-BCR-01 Backup coverage, protection and isolation
- Mandatory
- Yes
- Severity
- Critical
- Applies
- All scopes
- SecurityInspect Verified profiles
- VP-CLD
Control objective
Every in-scope system of record can be restored after deletion, corruption, ransomware or loss of a provider account, because backups exist at the needed frequency and at least one copy is out of an attacker's reach.
Testable requirement
- 1.The applicant shall back up every in-scope system of record, including the configuration needed to rebuild it (infrastructure-as-code, application configuration, and escrowed secrets under SIAS-CRY-03) and data held in SaaS services where the applicant is responsible for recovery, at a frequency that meets the RPO set under SIAS-BCR-03 (where no RPO is set: at least daily).
- 2.At least one backup copy of each system of record shall be an isolated backup copy.
- 3.Backups shall be encrypted to the SIAS cryptographic baseline (SIAS-CRY-02), and the keys needed to restore them shall remain available if the production environment or its key management service is lost (for example keys held in the isolated account or escrowed).
- 4.Deleting backups, shortening retention or disabling backup jobs shall require a role separate from routine production administration, protected by multi-factor authentication, and every such action shall be logged and raise an alert.
- 5.Backup jobs shall be monitored. A failed or missed job for a system of record shall alert a named owner and be resolved or escalated within 1 business day.
- 6.Backup retention shall be documented and shall keep restore points for at least 30 days, so that data can be recovered from before a compromise that is discovered late.
Applicability and scope
All scopes; cannot be marked not applicable. SecurityInspect Verified profiles: VP-CLD (systems of record in the named tenants or accounts; where the isolated copy is held outside those accounts, its location is included in the check).
Pass criteria
- 1.For every system of record, the job history in the look-back period shows a successful backup in at least 95% of RPO intervals and no gap longer than twice the RPO (A1, M2).
- 2.Every system of record has at least one isolated copy that no production identity can delete, overwrite or shorten the retention of (A2, M3).
- 3.Backups are encrypted, and restore keys are available independently of the production environment (A3, M4).
- 4.Backup deletion, retention changes and job disabling require a separate role protected by multi-factor authentication, and are logged and alerted (A2, E5).
- 5.Failure alerts reach a named owner and are resolved or escalated within 1 business day (M5, E5).
- 6.Restore points are kept for at least 30 days (E1, E2).
- 7.A4 finds no data store holding Confidential or Restricted data outside backup scope without a documented reason (for example a cache rebuilt from a backed-up source).
Severity
Critical. A system of record without an isolated copy, or backups that production identities can delete in full, is a Critical failure. Lowering one level is possible only for a partial failure (for example a missed RPO on a single system where an isolated copy no older than twice the RPO exists), with written rationale, quality-reviewer concurrence and the second independent reviewer's agreement; the control is still Not met until remediated and retested.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(7)(ii)(A), §164.310(d)(2)(iv)
- PCI DSS v4.0.1
- No direct mapping
- Trust Services Criteria
- CC9.1, A1.2
- ISO/IEC 27001:2022
- A.8.13
- Theme (SecurityInspect wording)
- complete, protected and isolated backups
SIAS-BCR-02 Restore testing against recovery objectives
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
The applicant knows from actual restores, not from backup reports, that it can recover its systems of record within its recovery objectives.
Testable requirement
- 1.The applicant shall perform a full restore test of each Tier 1 system at least every 12 months, and restore other systems of record on a rotation so that each is restored at least every 24 months.
- 2.The applicant shall perform file- or record-level restore spot checks from the isolated backup copy at least quarterly.
- 3.Each test shall restore into an environment separated from production, and measure the elapsed time and the age of the restored data against the RTO and RPO.
- 4.Each test shall confirm that restored data is complete and usable by a documented check (for example application start-up, record counts, checksums or a functional test).
- 5.Test results shall be recorded with the date, scope, measured times, the result against the objectives, issues found and actions taken. A failed test shall be repeated successfully within 60 days after correction.
- 6.A documented restore procedure shall exist for each Tier 1 system and shall be updated after each test.
Applicability and scope
All scopes; cannot be marked not applicable. SecurityInspect Verified profiles: not part of VP-EXT, VP-APP or VP-CLD.
Pass criteria
- 1.Every Tier 1 system has a recorded full restore test within the preceding 12 months, corroborated by platform records (A1, M2).
- 2.Quarterly spot checks from the isolated copy are recorded for the look-back period.
- 3.Recorded results meet the RTO and RPO, or each failure was corrected and repeated successfully within 60 days (A2, A3).
- 4.The observed restore (M3) completes, passes the documented check, and its time and data age are within the RTO and RPO. Where a full RTO measurement is impractical during fieldwork, the restore of the selected data set completes and its duration is consistent with the recorded tests.
- 5.Restore procedures exist for every Tier 1 system and were updated after the most recent test (M4).
Severity
High. If the observed restore (M3) fails and no successful restore of that Tier 1 system from the isolated copy can be shown, SecurityInspect also records a Critical finding against SIAS-BCR-01, because the backups are not shown to be restorable.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(7)(ii)(B), §164.308(a)(7)(ii)(D)
- PCI DSS v4.0.1
- No direct mapping
- Trust Services Criteria
- A1.3
- ISO/IEC 27001:2022
- A.5.30, A.8.13
- Theme (SecurityInspect wording)
- proven restores within recovery objectives
SIAS-BCR-03 Business impact analysis and recovery objectives
- Mandatory
- No
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
Recovery priorities and objectives come from an analysis of what the business and its customers need, not from what the backup tool happens to do.
Testable requirement
- 1.The applicant shall document a business impact analysis (BIA) for the in-scope services that identifies: essential business processes and customer-facing services; the in-scope systems and third parties each depends on; the impact of disruption over time; and the maximum tolerable downtime.
- 2.The BIA shall set an RTO and an RPO for each in-scope system of record and identify the Tier 1 systems.
- 3.The RTO and RPO values shall be consistent with any availability or recovery commitments the applicant makes to customers (contracts or published service levels).
- 4.The BIA shall be reviewed at least every 12 months and after each material change (SIAS-CMC-02), and approved by an accountable business owner.
Applicability and scope
All scopes; cannot be marked not applicable. SecurityInspect Verified profiles: not part of VP-EXT, VP-APP or VP-CLD.
Pass criteria
- 1.The BIA contains every element in testable requirement 1 (M1).
- 2.Every system of record has an RTO, an RPO and a tier (A1).
- 3.No RTO or RPO is inconsistent with a customer commitment (M3).
- 4.The BIA was reviewed and approved within the 12 months before fieldwork and after each material change in the look-back period (A3, M4).
- 5.The dependencies of every sampled essential service are complete (M2).
Severity
Medium. No escalation trigger.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(7)(ii)(E)
- PCI DSS v4.0.1
- No direct mapping
- Trust Services Criteria
- CC9.1
- ISO/IEC 27001:2022
- A.5.30
- Theme (SecurityInspect wording)
- recovery priorities set from business impact
SIAS-BCR-04 Business continuity and disaster recovery plan
- Mandatory
- No
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
When a major disruption happens, people know who decides, what to do first and how to keep essential services running with their security safeguards in place while systems are recovered.
Testable requirement
- 1.The applicant shall maintain a business continuity and disaster recovery plan for the in-scope services that defines: activation criteria and who may activate the plan; roles, deputies and contact details; recovery order based on the BIA tiers; recovery procedures for each Tier 1 system (which may reference the SIAS-BCR-02 procedures); how essential processes continue during an outage, including manual workarounds; how access control, logging and encryption are kept in place during emergency operation; communication with customers, staff and key suppliers; and criteria for returning to normal operation.
- 2.The plan shall be available to the people named in it when primary systems, the identity provider or the corporate network are unavailable (for example an offline or separately hosted copy).
- 3.The applicant shall exercise the plan at least every 12 months through a tabletop or functional exercise that includes loss of a Tier 1 system or of a key provider, and shall record lessons learned and actions.
- 4.The plan shall be reviewed after each exercise, each activation and each material change, and at least every 12 months.
Applicability and scope
All scopes; cannot be marked not applicable. A combined incident response and continuity plan meets this control when it contains every element in testable requirement 1. SecurityInspect Verified profiles: not part of VP-EXT, VP-APP or VP-CLD.
Pass criteria
- 1.The plan contains every element in testable requirement 1 and every Tier 1 system (M1, A2).
- 2.The out-of-band retrieval succeeds (M2).
- 3.An exercise meeting testable requirement 3 took place within the 12 months before fieldwork, with lessons and actions recorded, and its actions are closed or tracked (M3, A3).
- 4.Contact details for every sampled role are current (M4).
- 5.The plan was reviewed within 12 months and after each exercise, activation and material change in the look-back period (A1).
Severity
Medium. No escalation trigger.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(7)(i), §164.308(a)(7)(ii)(B), §164.308(a)(7)(ii)(C)
- PCI DSS v4.0.1
- 12.10
- Trust Services Criteria
- CC9.1, A1.3
- ISO/IEC 27001:2022
- A.5.29, A.5.30
- Theme (SecurityInspect wording)
- practiced plan for major disruption
SIAS-BCR-05 Capacity and redundancy of critical services
- Mandatory
- No
- Severity
- Low
- Applies
- Conditional — the applicant makes availability commitments to customers for in-scope services (in a contract, a published service level or a status-page commitment)
- SecurityInspect Verified profiles
- None
Control objective
Services that the applicant commits to keeping available have enough capacity and no untreated single point of failure.
Testable requirement
- 1.For each in-scope service covered by an availability commitment, the applicant shall document how the service is made redundant: components deployed across more than one failure domain (for example availability zones, hosts or sites), or a documented and tested failover, sized to meet the commitment.
- 2.The applicant shall monitor capacity for those services (compute, storage, database connections, network and third-party quotas) with alert thresholds that leave time to act (an alert at 80% of any hard limit), and shall review capacity trends at least quarterly.
- 3.Internet-facing services covered by an availability commitment shall be protected against volumetric denial-of-service attacks in proportion to the commitment (for example through a provider's protection service or a content delivery network).
- 4.Every single point of failure identified in these services shall be recorded in the risk register (SIAS-RSK-03) with a treatment decision.
Applicability and scope
Conditional — the applicant makes availability commitments to customers for in-scope services (in a contract, a published service level or a status-page commitment). Marking it not applicable needs a quality-reviewer-approved rationale showing that no such commitment exists. SecurityInspect Verified profiles: not part of VP-EXT, VP-APP or VP-CLD.
Pass criteria
- 1.Every single-failure-domain component of a committed service has a risk-register entry with a treatment decision (M2).
- 2.Capacity alerts with thresholds are configured for the main capacity metrics (A2).
- 3.Capacity reviews took place at the required frequency in the look-back period (M3).
- 4.Denial-of-service protection is in place for internet-facing committed services (A3).
- 5.The documented redundancy matches the observed configuration (E1, A1).
Severity
Low. No escalation trigger.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- No direct mapping
- Trust Services Criteria
- A1.1
- ISO/IEC 27001:2022
- A.8.6, A.8.14
- Theme (SecurityInspect wording)
- capacity and redundancy for committed services
