ISO 27001 is the international standard for information security management. This checklist will help you get started with your ISO 27001 compliance journey.

1 Introduction

Welcome to the audit process for ISO 27001 compliance, the international standard for Information Security Management Systems (ISMS). Your role as the auditor is crucial in assessing organizations' adherence to ISO 27001 requirements, ensuring the protection of information assets.

ISO 27001 provides a systematic approach to managing sensitive information and mitigating information security risks. This audit checklist is designed to evaluate an organization's ISMS effectiveness, covering policies, risk management, staff awareness, access control, incident response, and monitoring.

Your expertise as the auditor will help identify vulnerabilities, provide recommendations, and enhance information security practices. Stay objective, impartial, and maintain confidentiality throughout the process.

Thank you for your commitment to promoting information security and ensuring ISO 27001 compliance. Together, we can strengthen organizations' ability to protect valuable information assets and establish resilient security frameworks.

5 Management direction for information security
5.1
5.1.1 Policies for information security

These include policies like the high-level Information Security policy, Third Party Risk management policy, Network Security policy, Secure Software Lifecycle Development policy, and any other policy mentioned throughout the clauses and also that form part of the Annex A list of controls.


These include formal approval which should reflect in the document version control and revision section.


These include posting policies on the company portal (if available) or sending out mailer communications.


5.1.2 Review of the policies for information security

These include formal approval which should reflect in the document version control and revision section.


This can be a periodic interval determined by the organization but at a minimum, yearly is required.


An example of a major change could be the migration of on-premises servers to a public cloud. An example of a minor change could be the introduction of a new configuration management system that changes the existing workflow.


6 Organisation of information security


6.1 Internal Organisation


6.1.1 Information security roles and responsibilities


Some examples of roles and responsibilities include Chief Information Security Officer (CISO), Security Analyst, Security Engineer, and their daily tasks.


6.1.2 Segregation of duties


This is a very important Security concept that aims at ensuring that no single person has power enough to cause havoc. For example, A Firewall Administrator should not be allowed to create his/her own account, assign permissions and also approve them. More information can be found in this article.


6.1.3 Contact with authorities


There should be a process in place to report incidents when needed to local authorities including law enforcement. Sometimes these may be required by local laws and regulations. The processes should be documented.


There should be a process in place to report incidents when needed to local authorities including law enforcement. Sometimes these may be required by local laws and regulations. The processes should be documented.


6.1.4 Contact with special interest groups


Security Professionals can do so by registering at the local ISC2 or ISACA chapters for example.


6.1.5 Information security in project management


Think of this as an Information Security Risk Assessment for any new projects. For example, imagine a business team is planning to develop an in-house tool to accomplish a specific business objective, so it becomes important to understand the security risks from a Secure Software Development Lifecycle (SSDLC) perspective and the organization could have standard checklists for these assessments.


6.2 Mobile devices and teleworking


6.2.1 Mobile device policy


This is typically applicable to companies issuing handheld devices to employees or allowing employees to bring their own devices and connect to the company network. Device Security becomes an important component then and some solutions that can help with that are Mobile Device Management solutions.


These include formal approval which should reflect in the document version control and revision section.


6.2.2 Teleworking


Teleworking refers to working from anywhere which is very prevalent today in the hybrid way of working.


These include formal approval which should reflect in the document version control and revision section.


This typically is part of a procedural document as part of the organization's Identity and Access Management (IAM) strategy and should detail how employees are granted access from outside of the organization's network to inside to access corporate or production applications. E.g. Procedures regarding how employees have to log in to a VPN solution in order to access the organization's internal network.


This should form part of a Security Awareness training.


7 Human resources security


7.1 Prior to employment


7.1.1 Screening


Background verification checks include criminal background checks, educational background checks, etc.


Typically this sits within the HR function but organizations are free to appoint appropriate management authority. The 27001 standard gives that flexibility to organizations.


This is more for the Legal department to check the compliance of the background checks. For example, in certain countries, conducting a criminal background check against somebody might not be allowed by local laws.


This can be tied to the business risk of not complying with 27001 which may result in loss of customers, loss of reputation, etc.


7.1.2 Terms and conditions of employment




7.2 During employment


7.2.1 Management responsibilities


Security is everyone's responsibility. Some organizations make this part of Manager's job responsibilities to drive security-related conversations in everyday work.



7.2.2 Information security awareness, education and training



7.2.3 Disciplinary process




7.3 Termination and change of employment


7.3.1 Termination or change of employment responsibilities


This typically is a combination of HR-related processes and Identity and Access Management (IAM) procedures. For e.g.

1) Are User IDs immediately disabled upon termination

2) Are rights and permissions for the existing role removed (if no longer required) if the employee switches roles etc?


This can be part of a Non-Disclosure Agreement Clause or an electronic acknowledgment of having read the Information Security Policy.


Some examples include automated Identity and Access Management solutions to enforce the principle of least privilege giving employees only the rights they need to perform their jobs.


8 Asset management


8.1 Responsibility for assets


8.1.1 Inventory of assets


This could be an automated inventory like Service Now or a spreadsheet (which might not work for bigger organizations with lots of assets). Also, assets here refer to all software and hardware assets.


This could be an automated inventory like Service Now or a spreadsheet (which might not work for bigger organizations with lots of assets). Also, assets here refer to all software and hardware assets.


8.1.2 Ownership of assets


Also referred to as an Asset Owner, all Software and Hardware Assets must have ownership. This is important to be able to mitigate any Information Security risks.


8.1.3 Acceptable use of assets


An Acceptable Use Policy (AUP) typically describes the policies around how an organization's assets should be handled and the DOs and DONTs. Just like any other policies, these could be posted on the company intranet or through internal mailer campaigns.


An Acceptable Use Policy (AUP) typically describes the policies around how an organization's assets should be handled and the DOs and DONTs. Just like any other policies, these could be posted on the company intranet or through internal mailer campaigns.


8.1.4 Return of assets



8.2 Information classification


8.2.1 Classification of information


Information Classification is necessary to understand the criticality of data to the organization as data, after human resources, is the most valuable asset for an organization. Appropriate Security controls can be applied only if the classification of data is known. Data classified as "public" might not require the same level of controls as data classified as "confidential".


8.2.1.2

This should be a documented policy detailing what are the different types of data processed by the organization and what are their clarification criteria. For example, a Credit Card might be classified as confidential whereas the company careers page might have to be classified as "public".


8.2.2 Labelling of information


This could be an automated process where software could be utilized to automatically assign labels to files and documents or it can be a manual process where employees assign classification labels based on the company's classification criteria.


8.2.3 Handling of assets


There should be procedures for handling data belonging to different classification types. For example, "confidential data" may mandatorily need encryption controls but data classified as "public" may not.


The policies and procedures around data classification and handling of data should be communicated to all employees and contractors via appropriate means.


8.3 Media handling


8.3.1 Management of removable media


Removable media refers to things like USB drives, external drives, etc. Since information can be stolen via those media, certain security controls can be made applicable and also policies and procedures can be built around those.


This relates to how employees can request access to use certain removable media like USB sticks in company laptops for example. Salespeople might need those from time to time. There should be strict processes on how to govern those including issuance, approval, usage and return.


The policies and procedures around removable media should be communicated to all employees and contractors via appropriate means.


8.3.2 Disposal of media


Some procedures include degaussing and shredding and should be performed in an environmentally friendly way and also in a way that residual data cannot be extracted.


8.3.3 Physical media transfer


Transportation of media should have policies and procedures around it. For example, only company-approved vendors are allowed to move disks from one data center to another center, if the disks contain data that are labeled "confidential", more stringent security controls like access controls and encryption might apply, etc.


Transportation of media should have policies and procedures around it. For example, only company-approved vendors are allowed to move disks from one data center to another center, if the disks contain data that are labeled "confidential", more stringent security controls like access controls and encryption might apply, etc.


9 Access control


9.1 Business requirements for access control


9.1.1 Access control policy


An access control policy defines how an organization provides secure access to its systems for its users. It details the authentication, authorization and auditing (AAA) statements. Additionally, procedures should define how those policy statements are put into action.


The policy should be commensurate with business risks i.e. appropriate levels of access controls should be applied based on the classification of systems and the risks they pose to the business.


The policies and procedures around access control should be communicated to all employees and contractors via appropriate means.


9.1.2 Access to networks and network services


Also known as need to know, users or systems or services should only have access to the resources they need to accomplish their job and nothing else. Additional guidance can be found here.


9.2 User access management

Requirements A.9.2.1 to A.9.2.6 detail having thorough Identity and Access Management procedures in place which should cover how the organization manages a user, a system or a service's IAM lifecycle- from creation all the way to termination (in case of users) or decommissioning (in case of services/systems).


9.2.1 User registration and de-registration



9.2.2 User access provisioning



9.2.3 Management of privileged access rights



9.2.4 Management of secret authentication information of users



9.2.5 Review of user access rights



9.2.6 Removal or adjustment of access rights



9.3 User responsibilities


9.3.1 Use of secret authentication information


Examples of these include sharing root Linux admin passwords for "admins only" and break-glass account passwords. The organization should detail how these are shared with each other- for e.g. through LastPass, etc.


The policies and procedures should be communicated to all employees and contractors via appropriate means.


9.4 System and application access control


9.4.1 Information access restriction


This is basically the translation of policy statements written in A.9.1.1 into technical, administrative or physical controls.


9.4.2 Secure log-on procedures


This goes back to how the organization has defined the IAM procedures. The key to this is having a risk-based approach, meaning more sensitive systems might have stricter security requirements than low-sensitive assets.


9.4.3 Password management system


Passwords should be complex enough and the organization should follow industry standards like a 12-character password with special characters, numbers, etc.


Passwords should be complex enough and the organization should follow industry standards like a 12-character password with special characters, numbers, etc.


9.4.4 Use of privileged utility programs


Privilege Utility Programs are programs that can access systems or services through API calls for example or through service-to-service authentication. These should be tightly controlled using the same IAM principles.


9.4.5 Access control to program source code


Source Code is the organization's crown jewel and should be protected with the strongest of IAM controls.


10 Cryptography


10.1 Cryptographic controls


10.1.1 Policy on the use of cryptographic controls


The policy should detail the usage of cryptographic controls commensurate with the data classification policy and also should state the usage of industry standards and secure protocols like AES, RSA, etc. The policy should also take into account any compliance regulations. For e.g. if a certain compliance framework doesn't mandate the use of 3DES, it should be used.


10.1.2 Key management


Key Management is one of the most aspects of cryptography, and there should be policies and procedures governing how keys are generated, maintained and expired.


11 Physical and environmental security


11.1 Secure areas


11.1.1 Physical security perimeter


A perimeter is a security boundary that the organization controls and there should be one with appropriate access controls.


Just like Network Segmentation, physical environments can also be segregated based on the sensitivity of data and can be completely isolated. e.g. by using different racks or cages in data centers.


11.1.2 Physical entry controls


There should be designated secure areas where only authorized personnel are allowed to enter. For e.g. Security Personnel or Admins only. These should be well protected by appropriate access control systems and even combined with multi-factor authentication like a badge and a biometrics entry for example.


11.1.3 Securing offices, rooms and facilities


Security should be an integral part of not only systems security but also physical security. Appropriate physical security controls should be put into place.


Appropriate processes and procedures should be maintained for physical security. NIST SP 800-12 provides guidance.


11.1.4 Protecting against external and environmental threats


Risk Assessments should be conducted on a periodic basis to evaluate risks against those mentioned and appropriate controls should be put into place.


11.1.5 Working in secure areas


There should be designated secure areas where only authorized personnel are allowed to enter. For e.g. Security Personnel or Admins only. These should be well protected by appropriate access control systems and even combined with multi-factor authentication like a badge and a biometrics entry for example.


The policies and procedures around physical security should be communicated to all applicable stakeholders.


Examples of technical controls include badges and biometrics implementation. Examples of administrative include logging visitors in an entry system, and examples of physical security include bollards, etc.


11.1.6 Delivery and loading areas



Again, appropriate technical, administrative and physical security controls should be applied


Segregation remains one of the most important security controls and it is applicable even in this case.


11.2 Equipment


11.2.1 Equipment siting and protection


Locations that are prone to environmental hazards expose the organizations to more risks, which should be considered in the risk assessments. Appropriate backup strategies should be considered, for example, considering a cloud service provider that has access to various geographical regions and availability.


This should specifically be part of the physical security risk assessments to satisfy the requirements of the ISO 27001 standard. Appropriate access controls should be established.


11.2.2 Supporting utilities


The organization should make sure that single points of failure are eliminated, be it for power generation, HVAC systems, etc. so the business operations are able to continue in the event of a failure.


Periodic testing should be conducted. There could be table tops, walkthroughs, simulation drills or full interruption tests.


11.2.3 Cabling security


This should be part of the overall physical security risk assessments.


TEMPEST as it is called, is a set of guidelines and requirements, that organizations can use or check to see if the service providers use to help with these set of requirements.


11.2.4 Equipment maintenance


Rigorous maintenance procedures should be carried for making sure that equipment is still fit for purpose.


11.2.5 Removal of assets


Asset removal should have its set of procedures and including checks during removal, transportation and offloading.


Spot checks should be established to make sure the procedures are carried out in accordance with the policy.


11.2.6 Security of equipment and assets off-premises


Any assets if transferred off-site should be subject to the same level of security controls (as applicable).


The policies and procedures around physical security should be communicated to all applicable stakeholders.


11.2.7 Secure disposal or reuse of equipment


If the organization decides to reuse assets because of cost or environmental reasons, there should be appropriate policies around it.


More information about degaussing can be found here.


11.2.8 Unattended user equipment


There should be no unattended equipment and if found should be dealt with by categorizing, finding the owners and placing it in the appropriate secure location as defined by policies and procedures.


The controls could be a mix of technical, administrative or physical controls. There are even automated tools available in the market nowadays to help identify unattended and rogue devices. Armis is an example.


11.2.9 Clear desk and clear screen policy


This is to protect against information exposure as some employees inadvertently leave passwords or sensitive information on notepads at the desks. That's just one example but overall hygiene is necessary to protect against various information exposures.


Regular enforcement of the policy, spot checks and disciplinary actions should be determined.


12 Operations security


12.1 Operational procedures and responsibilities


12.1.1 Documented operating procedures


All operational procedures should be documented. These could be the deployment of servers and applications, running code reviews, rolling out upgrades, patches, etc.


The policies and procedures around operational security should be communicated to all applicable stakeholders.


12.1.2 Change management


Change Management is one of the most important aspects of Security and has to be integrated into all operations. Any code changes, platform changes, personnel changes, upgrades, etc.- minor or major has to undergo a change management process and have to be approved before the system is deployed to production.


12.1.3 Capacity management


Capacity Management is also very important for measuring against downtime and should be evaluated and reviewed constantly. Nowadays, with the advent of the cloud, capacity management is built into the cloud and organizations can leverage many Cloud Service Providers providing more scalability and agility.


12.1.4 Separation of development, testing and operational environments


This refers to the segmentation of different environments based on IP addressing schemes and Firewall Access Control Lists. The concept of micro-segmentation is also prevalent now where systems inside of the environments can also be appropriately segmented in order to maintain security levels and follow a Zero Trust approach.


12.2 Protection from malware


12.2.1 Controls against malware


This includes the use of anti-malware amongst other tools that are available in the market. Extended Detection and Response (EDR) tools are getting popular to combat Ransomware and other malware.


This includes strong network segmentation controls to prevent the lateral movement of malware.


This ties back to the controls stated in A.16


12.3 Backup


12.3.1 Information backup

This should be part of the overall business continuity/disaster recovery process. ISO 22301 provides an excellent framework for this. Also, the BCI GPG is a good resource.






12.4 Logging and monitoring


12.4.1 Event logging


Various logs need to be generated from systems (applications, databases, servers, etc.) and stored for analysis purposes to hunt for threats or for later forensic analysis purposes. These could be access logs, VPN logs, permissions and rights change logs, etc. The systems storing, processing and transmitting the logs should also be protected with all applicable security controls in order to prevent tampering with the logs.


12.4.2 Protection of log information


Same as above.


12.4.3 Administrator and operator logs


Same as above.


12.4.4 Clock synchronization


GitHub has published a list of top 10 public NTP servers.


12.5 Control of operational software


12.5.1 Installation of software on operational systems


There should be appropriate mechanisms in place to restrict users from installing unapproved software. These could be requiring a username and password for authentication before allowing software to be installed or simply whitelisting only approved software.


12.6 Technical vulnerability management


12.6.1 Management of technical vulnerabilities



There should be a combination of technical and administrative controls to assess vulnerabilities using scanners like Tenable and then remediating those based on timelines set per the criticality of the asset.


12.6.2 Restrictions on software installation


There should be appropriate mechanisms in place to restrict users from installing unapproved software. These could be requiring a username and password for authentication before allowing software to be installed or simply whitelisting only approved software.


12.7 Information systems audit considerations


12.7.1 Information systems audit controls


Organizations should have an unbiased auditing process with an audit committee that preferably directly reports to the board of directors. And the audits can be time-consuming so that has to be kept in mind.


Same as above.


13 Communications security


13.1 Network security management


13.1.1 Network controls


This includes a combination of policies and procedures depicting appropriate network management procedures with security in mind. For example using SSH and not Telnet to remote connect to Network Swtiches, following appropriate secure benchmarks for configuration, etc. Center for Internet Security (CIS) provides good guidance on this.


13.1.2 Security of network services


Security Risk Management should be an integral part of the organization's business operations and this is no different. Things like:

1) Is the vendor recognized?

2) Can the vendor's equipment support the organization's secure baseline configurations etc. should be kept in mind.


The organization's network security requirements should be made part of the third-party contracts or compensating controls should be established where they cannot be met by the third party.


Examples of these include Firewall troubleshooting procedures if the vendor is a Managed Security Service Provider (MSSP).


13.1.3 Segregation in networks


This refers to the segmentation of different environments based on IP addressing schemes and Firewall Access Control Lists. The concept of micro-segmentation is also prevalent now where systems inside of the environments can also be appropriately segmented in order to maintain security levels and follow a Zero Trust approach.


13.2 Information transfer


13.2.1 Information transfer policies and procedures


This basically refers to using secure channels like SSH, TLS, etc.


The policies and procedures should be communicated to all employees and contractors via appropriate means.


Access Controls should be implemented with the principle of least privilege in order to prevent abuse of information sharing.


13.2.2 Agreements on information transfer


The contractual agreements with third parties should replicate requirements resulting from A.13.2.1.


13.2.3 Electronic messaging


The scope of A.13.2.1 should cover messaging systems like Slack for example, where policies should dictate whether or not sensitive data should be transmitted and if yes, how the data should be transmitted.


13.2.4 Confidentiality or nondisclosure agreements


This is important from an Information Security and Legal perspective.


There should be periodic reviews.


Records should be maintained which sometimes can also be dictated by regulations.


14 System acquisition, development and maintenance


14.1 Security requirements of information systems


14.1.1 Information security requirements analysis and specification


Appropriate Information Security technical assessments have to be carried out when for example an entire fleet of Linux CentOS 7 servers are updated to CentOS 8. These reviews could include:

1) Do the same baseline configurations apply?

2) Will the new operating platform support the existing malware solution, etc?


Same as above.


14.1.2 Securing application services on public networks


This basically refers to using TLS1.2 or above with secure ciphers which are now the standard encryption protocols for secure web transmissions over the internet.


14.1.3 Protecting application services transactions


This basically refers to using appropriate hashing algorithms or other integrity checkers in order to maintain non-repudiation of data.


14.2 Security in development and support processes


14.2.1 Secure development policy


There are many secure SDLC frameworks that organizations can adopt. Some of them are OpenSAMM, OWASP Secure SDLC, Microsoft SDLC, Cisco SDLC, etc.


Same as above.


14.2.2 System change control procedures


Change Management is one of the most important aspects of Security and has to be embedded in the SDLC. Any code changes, minor or major have to undergo a change management process and have to be approved before the code is pushed to production. Since a lot of organizations are moving to a DevOps model, many source code management tools like GitLab provide features like Merge Request approvals in order for developers to review other developers' code before pushing those into production.


14.2.3 Technical review of applications after operating platform changes


Appropriate Information Security technical assessments have to be carried out when for example an entire fleet of Linux CentOS 7 servers are updated to CentOS 8. These reviews could include:

1)Do the same baseline configurations apply?

2) Will the new operating platform support the existing malware solution, etc?


14.2.4 Restrictions on changes to software packages


This should be part of the Secure SDLC framework that the organization adopts in A.14.2.1.


14.2.5 Secure system engineering principles


This should be part of the Secure SDLC framework that the organization adopts in A.14.2.1. Systems refers to all systems (Applications, Databases, APIs, etc.). So the policy can be a Secure "Systems" Lifecycle Development Policy and can include aspects of "Software" as well.


14.2.6 Secure development environment


The organization has to create separate environments for Development/Testing and Production. These environments should be segregated from each other with appropriate security controls like segregation of duties, etc.


The organization has to establish processes to ensure that these environments are used in accordance with the established procedures- The development environment is only used for Development and so forth.


14.2.7 Outsourced development


If Development work has been outsourced, the organization should establish appropriate third-party risk management procedures to monitor. Remember, the "accountability" of shipping secure software still would be like with the organization. This could be part of the Third Party Risk Management policy and procedures defined in A15 below.


Tools like Snyk can help with that. This has become prevalent after the solar winds hack but unvetted third-party libraries can introduce vulnerabilities in the organization and have to be part of the overall Secure SDLC strategy.


14.2.8 System security testing


Same as A.14.2.3 but applies to all systems and not only software.


14.2.9 System acceptance testing


This should be part of the change management process. A Change Approval Board (CAB) should be established, appropriate change management flows should be defined with a classification of change types and what is that's required before accepting a new change.


14.3 Test data


14.3.1 Protection of test data


Test data used in Development should be used from either in-house methods or from recognized industry sources. The organization should develop appropriate access controls with the least privilege principles and other security controls to protect the test data.


Same as above.


15 Supplier relationships


15.1 Information security in supplier relationships


15.1.1 Information security policy for supplier relationships


Information Security and Right to Audit clauses should be included as part of the contracts so that appropriate reviews can be carried out on the supplier activities at any given point in time.


This includes integrating risk management processes throughout the vendor lifecycle, right from onboarding to offboarding of the suppliers. NIST has guidance on supplier risk management.


15.1.2 Addressing security within supplier agreements


Examples include appropriate encryption that has to be implemented while dealing with the organization's data.


If vendors are provided access to the organization's systems, the access controls should be in line with the organization's access control policy.


15.1.3 Information and communication technology supply chain


This is a subset of A.15.1.1


15.2 Supplier service delivery management


15.2.1 Monitoring and review of supplier services


This is an implementation of A.15.1.1. Companies like Shared Assessments have Standard Information Gathering Questionnaires that can help with this.


15.2.2 Managing changes to supplier services


Any changes to contracts should be vetted thoroughly from an Information Security lens to see if any controls are affected.


16 Information security incident management


16.1 Management of information security incidents and improvements


16.1.1 Responsibilities and procedures


16.1.1.1

NIST Computer Security Incident Handling Guide provides guidance on the incident management phases. Appropriate Roles and Responsibilities have to be defined for the Incident Management process.


16.1.2 Reporting information security events


Timely reporting is important from both a containment perspective and also might be required by various regulations.


Personnel will need to review and act upon incidents according to procedures defined in playbooks.


16.1.3 Reporting information security weaknesses


Organizations typically use a Vulnerability Scanning tool (e.g. Tenable) for this.


These should be communicated to all employees and contractors via appropriate means.


This has to be in accordance with a Vulnerability Management policy which should be established first, and which should contain details of severity and remediation timelines amongst other things. For example, a high-severity vulnerability with a CVSS score of 8.0-9.0 might have to be remediated within a timeframe of 7 days as compared to a low-severity vulnerability with a CVSS score of 1.0-3.0 that can be remediated within 1 month.


16.1.4 Assessment of and decision on information security events


Incidents and events can be classified according to priority levels. Several organizations use P1, P2 and P3 levels depending on the amount of damage an incident can have on the organization's business objectives.


16.1.5 Response to information security incidents


An Incident Response policy and a procedure document have to be established that details all phases starting from incident identification to the retrospective, and appropriate playbooks have to be established for different incident types. The NIST Computer Security Incident handling guide is an excellent resource for this.


16.1.6 Learning from information security incidents


Same as above.


16.1.7 Collection of evidence


The organization has to make sure that appropriate forensic procedures are established and followed after an incident occurs, and that also appropriate chain of custody is followed to ensure the validity of the evidence and to be able to support the evidence in a court of law.


Same as above.


17 Information security aspects of business continuity management


17.1 Information security continuity


17.1.1 Planning information security continuity


Examples of this include making sure that the backup systems in the redundant facilities have been implemented with the same level of Security controls.


17.1.2 Implementing information security continuity


An example would be continuity plans to make sure that the Security Operations Center (SOC) personnel are able to still detect and respond to attacks.


17.1.3 Verify, review and evaluate information security continuity


Periodic testing is required in order to validate that the plans will actually work during an adverse situation.


17.2 Redundancies


17.2.1 Availability of information processing facilities


This includes all forms of redundancy like dual power supply, backup systems, backup tapes, cloud services, etc.


18 Compliance
*


18.1 Compliance with legal and contractual requirements
*


18.1.1 Identification of applicable legislation and contractual requirements
*


This refers to whether the organization has identified applicable compliance regulations like PCI DSS if it stores, processes or transmits credit card data, GDPR if the organization processes data of individuals residing in the EU, etc. An applicable list of compliance requirements has to be well documented.


This refers to whether the organization has identified applicable compliance regulations like PCI DSS if it stores, processes or transmits credit card data, GDPR if the organization processes data of individuals residing in the EU, etc. An applicable list of compliance requirements has to be well documented.


18.1.2 Intellectual property rights
*


Several automated tools can help with this, manual efforts might not be scalable. Service Now is one such example.


Several automated tools can help with this, manual efforts might not be scalable. Service Now is one such example.


18.1.3 Protection of records
*


These refer to having appropriate physical and logical security measures in place which sometimes could be derived directly from different regulations like PCI DSS for example.


18.1.4 Privacy and protection of personally identifiable information
*


This refers to identifying personal data like GDPR data or any other classification types as required by local laws and regulations. Each regulation has its own set of controls for protecting data so those would have to be applied- for example, some regulations might require personal data to be encrypted with AES-256 while in storage.


This refers to identifying personal data like GDPR data or any other classification types as required by local laws and regulations. Each regulation has its own set of controls for protecting data so those would have to be applied- for example, some regulations might require personal data to be encrypted with AES-256 while in storage.


18.1.5 Regulation of cryptographic controls
*


Please refer to the encryption example above.


18.2 Information security reviews
*


18.2.1 Independent review of information security
*


Independent reviews here refer to both internal and external audits. An external audit can refer to the 27001 audits itself and internal audit functions are also present in most organizations. The word independent refers to the fact that the audit function should report independently to the board (for example) and not to the CISO.


18.2.2 Compliance with security policies and standards
*


Examples of these include whether their direct reports have completed security awareness training on time, whether Developers have completed Secure SDLC training, etc.


Examples of these include whether their direct reports have completed security awareness training on time, whether Developers have completed Secure SDLC training, etc.


18.2.3 Technical compliance review
*


These include regular control monitoring and keeping evidence. For example, patching all critical vulnerabilities within 30 days, and keeping evidence of the logs. Another example could be regular access control reviews for critical rights and permissions.


Signup and start

Details

Author 21RISK
Languages English
Length 185 Questions
Last modified Jun 12, 2023
Created Jun 12, 2023
Signup and start