ISO 27001 is the international standard for information security management. This checklist will help you get started with your ISO 27001 compliance journey.
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.
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.
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.
Some examples of roles and responsibilities include Chief Information Security Officer (CISO), Security Analyst, Security Engineer, and their daily tasks.
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.
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.
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.
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.
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.
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.
Security is everyone's responsibility. Some organizations make this part of Manager's job responsibilities to drive security-related conversations in everyday work.
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.
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.
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.
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.
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".
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".
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.
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.
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.
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.
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.
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.
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).
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.
This is basically the translation of policy statements written in A.9.1.1 into technical, administrative or physical controls.
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.
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.
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.
Source Code is the organization's crown jewel and should be protected with the strongest of IAM 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.
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.
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.
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.
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.
Risk Assessments should be conducted on a periodic basis to evaluate risks against those mentioned and appropriate controls should be put into place.
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.
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.
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.
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.
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.
Rigorous maintenance procedures should be carried for making sure that equipment is still fit for purpose.
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.
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.
If the organization decides to reuse assets because of cost or environmental reasons, there should be appropriate policies around it.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
The contractual agreements with third parties should replicate requirements resulting from A.13.2.1.
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.
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?
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.
This basically refers to using appropriate hashing algorithms or other integrity checkers in order to maintain non-repudiation of data.
There are many secure SDLC frameworks that organizations can adopt. Some of them are OpenSAMM, OWASP Secure SDLC, Microsoft SDLC, Cisco SDLC, etc.
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.
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?
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.
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.
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.
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.
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.
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.
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.
This is an implementation of A.15.1.1. Companies like Shared Assessments have Standard Information Gathering Questionnaires that can help with this.
Any changes to contracts should be vetted thoroughly from an Information Security lens to see if any controls are affected.
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.
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.
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.
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.
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.
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.
Examples of this include making sure that the backup systems in the redundant facilities have been implemented with the same level of Security controls.
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.
Periodic testing is required in order to validate that the plans will actually work during an adverse situation.
This includes all forms of redundancy like dual power supply, backup systems, backup tapes, cloud services, etc.
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.
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.
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.
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.
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.
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.
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.