Desktop control mapping under transition pressure
Vantage Logistics has a risk register with 62 risks and a Statement of Applicability that lists 114 controls from ISO 27001:2013 Annex A. The risk treatment plan maps each risk to one or more controls; 31 risks are treated only by controls that remain in 2022 Annex A, but 14 are treated by controls that were replaced or reorganised (for example, A.12.1.2 change management, A.14.2.5 secure system engineering, A.16.1.2 reporting security events). The information security manager plans a 'desktop mapping' exercise: convert the old control numbers to new ones, add the 11 new controls to the SoA as 'not applicable' with the justification 'no requirement identified', and reissue the risk assessment unchanged. The transition audit is in six months. The internal auditor notes that new controls such as threat intelligence (A.5.7), cloud services (A.5.23) and data leakage prevention (A.8.12) may be relevant because Vantage has moved its TMS to SaaS and has had two data-sharing incidents with partners in the last year.
1. Critique the proposed desktop mapping. Which clause 6.1 requirements are at risk, and what should the ISMS team do instead?
Read the worked answer
The desktop mapping treats the transition as a numbering exercise. Clause 6.1.2 requires risk assessment at planned intervals or when significant change occurs, using defined criteria and producing comparable results. Moving the TMS to SaaS and two data-sharing incidents are significant changes; reissuing the old assessment unchanged means the risk assessment no longer reflects the organisation. Clause 6.1.3 requires risk treatment options, a treatment plan and a Statement of Applicability with justified inclusions and exclusions. Adding the 11 new controls as 'not applicable - no requirement identified' is not a justification; the SoA must explain why each control is or is not relevant to the assessed risks. A.5.7, A.5.23 and A.8.12 may well be relevant given the SaaS move and the incidents. Instead, Vantage should refresh the risk assessment, identify changed and new risks, evaluate the new controls against those risks, update the treatment plan and SoA with reasons, and obtain management approval. The old-to-new mapping can be a clerical aid, but it cannot substitute for risk assessment. The auditor will look for a dated risk assessment that considers the SaaS migration and incidents, and SoA entries that are risk-based rather than copied.
2. How should the team decide whether A.5.7, A.5.23 and A.8.12 are applicable, and what would a defensible SoA entry look like for each?
Read the worked answer
Applicability starts from the risk assessment, not from the control list. For A.5.7 threat intelligence, the team should ask whether relevant threat information is already used, whether the logistics sector and partners present targeted threats, and whether the two incidents revealed a threat-awareness gap. If so, the control is applicable and should be implemented through defined sources, review cadence and a process for turning intelligence into action. For A.5.23 cloud services, the SaaS TMS makes cloud-specific supplier and configuration controls clearly relevant; the SoA should record the acquisition process, security requirements, monitoring and exit arrangements. For A.8.12 data leakage prevention, the data-sharing incidents are evidence that data flows and controls need review; DLP may be applicable, though the implementation could range from classification and blocking to monitoring. A defensible SoA entry states the control, applicability, the risk or reason for inclusion or exclusion, implementation status, and evidence reference. 'Not applicable - no requirement' is only acceptable if the context and risk assessment genuinely show no exposure; the two incidents make that hard to sustain.