6.1.3 Information security risk treatment (d) Statement of Applicability Specified In draft Done The Statement of Applicability (SoA) lays out the information risk and security controls that are relevant and applicable to your organization’s ISMS, as determined by your risk assessments or as required by laws, regulations or good practice. Cross-reference them against the controls recommended in ISO/IEC 27001 Annex A and ISO/IEDC 27002, plus any alternative/supplementary sources such as NIST SP800-53, ISO 31000, ISO/IEC 20000, ISO 22301 and 22313, IT-Grundschutz, the ISF Standard of Good Practice, assorted privacy laws and principles etc. Clarify whether the controls recommended in ISO/IEC 27001 Annex A are in scope and appropriate to your organization, if not providing reasoned justifications (e.g. strategic management decisions, formally recorded) to convince the auditors that you haven’t simply neglected, ignored or arbitrarily excluded them. 6.1.3 Information security risk treatment Risk treatment process Specified In draft Done Again it is up to you to determine precisely what is appropriate for your organization, using clause 6.1.3 plus guidance from and ISO 31000. Risk treatment decisions (e.g. selecting treatments including applicable controls) and the actions arising (e.g. implementing the controls or sharing risks) may be an integral part of the risk assessment process, or a distinct activity or phase. It could be a dedicated activity for information risk, or an integral part of enterprise risk management etc. Typical evidence includes a written policy and/or procedure for consistently deciding on and implementing appropriate information risk treatments. Convince the auditors that the process is operating correctly by providing relevant reports, your Risk Treatment Plan, entries in your risk register, metrics etc. You may prefer some sort of list, matrix or database structure, a program or project plan, or something else to explain the process through which information risks are being or to be controlled 6.2 Information security objectives and plans Specified In draft Done The ISO requirement to “retain documented information on the information security objectives” is vague too, so once more you have some latitude. A good approach is to start with the organization’s high level business objectives,
should be plainly evident (painfully obvious!) from the documentation that the ISMS is in normal operation, business-as-usual. Simply convince the certification auditors that the ISMS is operating sweetly. 8.2 Risk assessment results Specified In draft Done Information should be generated routinely by the risk assessment process noted in section 6.1.2. Examples include risk assessment reports, risk metrics, prioritized lists of risks, information risk inventories or catalogs or information risk entries in corporate risk inventories/catalogs etc. You may have meeting notices/invitations, minutes of meetings, risk workshop reports, rough notes from discussions arising, formal memoranda, emails expressing concerns about certain risks, or whatever. Again, collate sufficient material evidence to reassure the auditors that the process is generating useful outputs about information risks. 8.3 Risk treatment results Specified In draft Done How are you going to prove that identified information risks are being ‘treated’ in accordance with the process and decisions made? Your Risk Treatment Plan might usefully reference evidence/records confirming that risks have been and are being duly treated, such as control test reports, penetration test reports, control implementation project plans plus milestones and closure documents, purchasing and financial records for capital expenditure, metrics showing a reduction in the frequency and/or severity of the corresponding incidents etc., management review and audit reports, emails from management congratulating the ISMS team and awarding large bonuses etc. Particularly where substantial risks are accepted (including residual risks), there should be evidence such as signatures of the relevant risk or asset owners formally acknowledging that (thereby accepting accountability for any incidents arising!). 9.1 Metrics Specified In Done The ISMS generates various metrics that are used to monitor and information risks, controls and the ISMS itself in the intended direction. Evidence here includes security metrics in reports, systems, dashboards, presentations etc., plus proof that the metrics are being duly noted and acted upon e.g. memos, emails or rough notes expressing concern about adverse
A9.2.1 User registration A9.2.2 User access provisioning Specified In draft Done Working records from Security Admin typically include Done and actioned access request forms plus authorized signatory lists, logs and reports from automated access management systems, change authorizations, information exchanged with HR and Procurement (e.g. monthly lists of joiners and leavers, consultants/contractors, temps) etc. A9.2.3 Privileged user management A9.4.4 Use of privileged utilities Specified In draft Done Details of special arrangements to control privileged accounts (e.g. ROOT and auditor accounts) and privileged functions/utilities (e.g. system, security and database administration) especially on high-risk systems, firewalls, log management and intrusion detection systems, databases or other valuable/vulnerable information – typically policies, procedures and guidelines with operational records demonstrating that the processes are working properly and that changes to privileged accounts are reviewed and controlled. A9.2.4 Password management Specified In draft Done Policies and procedures for creating, communicating and changing passwords, PIN codes, crypto keys, physical keys etc. with operational records from Security Admin, access management systems etc. demonstrating that the processes are working properly. A9.2.5 Access rights reviews A9.2.6 Access rights adjustment Specified In draft Done Policies, procedures and notes or reports arising from periodic/ad hoc reviews, reconciliation and re-authorization of access rights including evidence that inappropriate rights have been identified, considered and addressed (possibly incident or change records). A9.3.1 Password security A9.4.3 Password management Specified In Done Policies, procedures and guidelines concerning the choice and enforcement of strong passwords, password secrecy, password vaults, password changes etc. A9.4.1 Information access restriction Specified In draft Done Procedures for restricting access to information and applications in line with the classification and handling rules set out in A8.2, plus records of their operation such as access reports from IT systems, databases, firewalls etc., change management records for significant access right changes etc.
confirmation/receipt for nonrepudiation, check-totals and message counts, keep-alive or heartbeat arrangements with null messages and alerts on link failure, diverse routing, emergency contacts etc.). A13.2.4 NDAs Specified In draft Done Discrete Non-Disclosure Agreements are the obvious evidence here, but also confidentiality clauses embedded in various agreements (e.g. consulting, professional advisors and employment contracts), and perhaps the associated policies, procedures, guidelines etc. detailing the controls to monitor and achieve compliance. A14.1.1 System security requirements A14.1.2 Securing public apps A14.1.3 Transaction security A14.2.1 Secure development A14.2.5 Security engineering A14.2.8 Security testing A14.3.1 Securing test data A14.2.9 Acceptance testing Specified In draft Done Strategies, policies, procedures and guidelines concerning how information risks are identified, assessed and treated in the course (throughout the entire lifecycle) of software/systems development activities (e.g. structured development methods with documented risk analysis, security design/selection, secure platforms, security services/functions/processes, secure development/coding, security and performance testing, implementation/configuration, post-installation verification, system maintenance and management activities, forms etc.) concerning the full breadth of application/system security requirements (e.g. security engineering, architecture and design, compliance with legal, regulatory, contractual, ethical and commercial obligations/expectation, business process/administrative controls, identification and authentication, access and privacy controls (including specifications, code, test data and test results), crypto, fraud controls, network/messaging security, malware controls, alarms and alerts, logging, security admin, data integrity, backups, resilience and recovery …), and possibly records demonstrating them in action (e.g. acceptance or authorization to proceed with implementation), preferably with evidence of a strong business drive and involvement. A14.2.2 Change control Specified In draft Obviously enough, the documentation includes change control policies, procedures and guidelines, plus less obviously change authorization and
are very tricky to identify, analyze and treat: remember Sendai! This control extends well into business continuity management, hence BC strategies, policies, arrangements etc. are probably partly relevant, as well as broader commercial strategies etc. A16.1.1 Incident management responsibilities A16.1.2 Incident reporting A16.1.3 Vulnerability reporting A16.1.4 Incident assessment A16.1.5 Incident response A16.1.6 Learning from incidents A16.1.7 Forensics Specified In draft Done [Information- or IT- or information security-related] incident management rôles, responsibilities and objectives, plus policies, procedures and guidelines (e.g. routine and emergency contact points), plus records/evidence concerning events/incidents reported, logged, analyzed, possibly escalated, addressed and resolved as evidence of compliance. The auditors will welcome evidence of a managed, measured, systematic, rational and effective process for handling incidents from cradle-to-grave, including post-incident wash-ups and substantive organizational changes to embody the learning. For bonus points, show-off your strong forensics capability, and demonstrate that you also discover, respond/react to and learn from near-misses and incidents affecting 3rd-parties. A17.1.1 Planning infosec continuity A17.1.2 Implementing infosec continuity A17.1.3 Verifying infosec continuity Specified In draft Done As literally worded, the standard is primarily concerned with ensuring the continuity of important information security activities and controls during a major incident or disaster … but you and I know that information security is generally a relatively minor consideration under such circumstances and is completely trumped by ensuring the continuity of core business activities, hence sensible documentation in this area includes business continuity strategies, policies, plans, procedures, test/exercise reports etc. demonstrating the effectiveness of the organization’s preparations, including but extending far beyond information/IT and indeed information risk and security activities. [ISO