SIAS-RSK-01 Risk assessment of the in-scope environment
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
The applicant identifies and rates the risks to the confidentiality, integrity and availability of in-scope systems and data on a documented, repeatable basis, so that its security decisions rest on known risks rather than assumptions.
Testable requirement
- 1.The applicant shall maintain a documented risk assessment methodology that defines the likelihood and impact criteria, the rating scale, the risk acceptance threshold, and who may perform and approve risk assessments.
- 2.The applicant shall complete a risk assessment of the whole certified scope at least every 12 months, and update it within 60 days after any material change reported under SIAS-CMC-02.
- 3.The risk assessment shall cover every in-scope asset class recorded under SIAS-AST-01 and SIAS-AST-02, every data type named in the scope declaration, and threats from external attackers, the workforce and third parties (SIAS-TPR-01).
- 4.The risk assessment shall record, for each risk, the affected assets, the threat and vulnerability, the likelihood and impact ratings, the resulting risk rating and a named risk owner.
- 5.A person holding the approval authority defined in the methodology shall approve the completed risk assessment, and the approval shall be dated.
Applicability and scope
All scopes; cannot be marked not applicable. Covers the certified scope as recorded in the signed scope declaration. An enterprise-wide risk assessment is accepted when it demonstrably includes the in-scope assets and data types. If SecurityInspect consulting personnel prepared or facilitated the risk assessment, the rules in the SIAS independence and impartiality rules apply before this control can be assessed. SecurityInspect Verified profiles: not part of VP-EXT, VP-APP or VP-CLD.
Pass criteria
- 1.A methodology exists that contains every element of testable requirement 1 (M1).
- 2.A completed risk assessment of the scope is dated within the 12 months before fieldwork, and every material change reported in the look-back was reflected within 60 days (M2, A3).
- 3.No in-scope asset class recorded under SIAS-AST-01 or SIAS-AST-02, and no data type in the scope declaration, is absent from the risk assessment; every sampled asset is covered (M3, A2); and M4 does not show a pattern of unidentified significant risks.
- 4.Every risk entry contains the fields in testable requirement 4 (A1).
- 5.The approval was given by an authorized person, and the dates in the document match the system metadata (M6, A3).
- 6.No more than one of the re-rated risks (M5) differs from the applicant's rating by more than one level without a documented explanation.
Severity
High. No control-specific escalation trigger. A backdated or fabricated risk assessment is an integrity failure under gate G0, not a severity question.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(1)(ii)(A)
- PCI DSS v4.0.1
- 12.3
- Trust Services Criteria
- CC3.1, CC3.2, CC3.3
- ISO/IEC 27001:2022
- 6.1.2, 8.2
- Theme (SecurityInspect wording)
- periodic documented analysis of in-scope risks
SIAS-RSK-02 Risk treatment and accountable risk acceptance
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
Every risk above the applicant's acceptance threshold receives a documented treatment decision with an accountable owner, and any risk that is accepted is accepted knowingly, by someone with authority, for a limited time.
Testable requirement
- 1.The applicant shall record a treatment decision (mitigate, avoid, transfer or accept) for every risk rated above its acceptance threshold, within 30 days of the rating.
- 2.Each mitigation shall have a named owner, the planned controls or actions, a target date and a status that is kept current.
- 3.Each acceptance shall record the rationale, the residual rating, any interim safeguards, the approver and an expiry date no more than 12 months after approval. The approver shall hold the acceptance authority defined in the methodology for that rating. Risks at the highest rating level shall be accepted only by an officer, managing member or owner of the applicant.
- 4.A mitigation that passes its target date shall be escalated to the approver and then completed, re-planned with a new date and a recorded reason, or accepted under requirement 3.
- 5.A transfer decision (for example insurance or a contractual allocation) shall identify the part of the risk that stays with the applicant, including the underlying safeguards, and that remaining part shall itself receive a treatment decision.
Applicability and scope
All scopes; cannot be marked not applicable. Covers every risk in the risk assessment (SIAS-RSK-01) and risk register (SIAS-RSK-03) that affects the certified scope. SecurityInspect Verified profiles: not part of VP-EXT, VP-APP or VP-CLD.
Pass criteria
- 1.A1 reports no risk above the threshold without a treatment decision, and every sampled decision was recorded within 30 days of the rating (M1).
- 2.Every sampled mitigation recorded as implemented is confirmed present and effective (M2, A2).
- 3.Every sampled acceptance has a rationale, residual rating, interim safeguards where stated, an authorized approver and an expiry no more than 12 months after approval, and no acceptance in the register is past its expiry without renewal or closure (M3, A1, A3).
- 4.No mitigation is more than 30 days past its target date without an escalation record (M4, A1).
- 5.Every transfer decision identifies and treats the remaining risk.
Severity
High. No control-specific escalation trigger. Where an untreated or accepted risk corresponds to a condition that meets a mandatory escalation trigger (§5.7), that condition is recorded as a separate Critical finding against the relevant technical control.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(1)(ii)(B)
- PCI DSS v4.0.1
- 12.3
- Trust Services Criteria
- CC3.2, CC5.1
- ISO/IEC 27001:2022
- 6.1.3, 8.3
- Theme (SecurityInspect wording)
- owned, time-limited treatment of identified risks
SIAS-RSK-03 Risk register and periodic review
- Mandatory
- No
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
The applicant keeps one current record of its risks and reviews it often enough that the record reflects changes in systems, threats, suppliers and incidents between full risk assessments.
Testable requirement
- 1.The applicant shall maintain one risk register for the certified scope (or several registers with a documented index) containing, for each risk: a unique ID, description, affected assets, owner, inherent rating, treatment, residual rating, status and last review date.
- 2.Risk owners shall review the register at least every 6 months, and the review shall be recorded with its date, participants and changes. A rolling review is acceptable when the records show every risk was reviewed within 6 months.
- 3.The register shall be updated within 30 days after each of these triggers: a security incident affecting the scope (SIAS-INC-03); a material change (SIAS-CMC-02); a Critical or High vulnerability that cannot be remediated within the SIAS-VPM-02 timeframes; a new or changed critical third party (SIAS-TPR-01).
- 4.The register shall keep the history of ratings and status changes for at least 12 months.
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.A1 reports no entry missing an owner, rating or status, and no more than 5% of entries missing any other required field.
- 2.The review frequency in testable requirement 2 is met (M2, A2).
- 3.Every trigger event tested was reflected within 30 days or has a recorded reason (M3, A3).
- 4.Rating and status history is kept for at least 12 months (E1).
Severity
Medium. No escalation trigger.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(1)(ii)(B)
- PCI DSS v4.0.1
- 12.3
- Trust Services Criteria
- CC3.4
- ISO/IEC 27001:2022
- 6.1.2, 8.2
- Theme (SecurityInspect wording)
- living risk record updated on change
SIAS-RSK-04 Threat intelligence in risk decisions
- Mandatory
- No
- Severity
- Low
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
The applicant learns about threats relevant to its technology and sector, and uses that information in risk and vulnerability decisions.
Testable requirement
- 1.The applicant shall document the threat information sources it monitors for the in-scope environment. At a minimum these shall include security advisories from the suppliers of in-scope operating systems, platforms, cloud services and key software, and the CISA Known Exploited Vulnerabilities (KEV) catalog.
- 2.The applicant shall assign a named role to review these sources, at least weekly for vulnerability and exploitation sources.
- 3.For each item that concerns in-scope technology, the applicant shall record a relevance decision (act, monitor or not applicable) within 7 days of publication, and route actionable items to vulnerability management (SIAS-VPM-02) or the risk register (SIAS-RSK-03).
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 documented sources include the minimum sources in testable requirement 1, and A2 shows no key supplier without a source (or the gap is explained).
- 2.A named role and the review frequency are documented (M1).
- 3.Every relevant KEV entry traced in M2 has a relevance decision within 7 days, and every actionable item reached vulnerability management or the risk register.
Severity
Low. No escalation trigger. (An unremediated KEV-listed vulnerability on an internet-facing asset is a Critical finding under SIAS-VPM-02, not under this control.)
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 6.3
- Trust Services Criteria
- CC3.2
- ISO/IEC 27001:2022
- A.5.7
- Theme (SecurityInspect wording)
- relevant threat information shapes decisions
