ISO 27001:2013 Documentation and Evidence

4.3ISMS Scope The ISMS Scope Statement defines the information assets your organization and ISMS is required to protect. ISO 27001 requirements state organizations must take into account the context of your organization, interested parties or stakeholders, and a description of your business location and org chart.
4.1Organization and contextCompany org chart, including key stakeholders
4.2StakeholdersList of key ISMS stakeholders that’s updated periodically. ISMS stakeholders include personnel that oversee and manage the ISMS, as well as those who depend on it to operate effectively.
4.4ISMS DescriptionSystem description documentation including details of the ISMS purpose and high level overview of the system architecture. This can include a boundary overview and/or a high level description of the ISMS IT infrastructure and system diagram. Often times these descriptions can be found in ISMS policies, procedures, and guidelines.
5.1LeadershipEvidence demonstrating company leadership is committed to maintaining and improving the ISMS. Documentation can include budgets, strategies, meeting minutes, and communications from senior management
5.2Information Security PolicyThe information security policy explain’s how management approaches information security. It defines how the company protects the confidentiality, integrity, and availability of sensitive data.
5.3Information Security Roles and ResponsibilitiesOrg charts and job descriptions including control owners responsible for particular security controls and processes
6.1.1Actions to address risks and opportunitiesISMS management meeting minutes, audit reports and recommendations, remediation plans and corrective actions.
6.1.2, 6.1.3Information Security Risk Assessment/Treatment Process and PlanDocumented Risk Assessment and Risk Treatment Process, which explains how you identify, evaluate, and prioritize risks. This document should also include how often you reviews and update your risk assessment and treatment plans.  Other documentation includes your Risk Treatment Plan, Risk register, and Risk matrix.
6.1.3Statement of ApplicabilityThe Statement of Applicability explains which Annex A security controls are — or aren’t — applicable to your organization’s ISMS.

It should list the controls your organization has selected to mitigate risk, explain why these controls were chosen for your ISMS, state whether the controls have been fully implemented, and explain why any controls were excluded
6.1.5Information Security & Project ManagementProject management methodologies, policies, procedures, planning documents that include any information risk and security guidelines. Documentation can include budgets, strategies, meeting minutes, and communications from senior management.
6.2Information Security Objectives and PlansDocument that outlines your organization’s business objectives and the risks associated with them, along with internal control objectives and metrics. Documentation can include budgets, strategies, meeting minutes, and communications from senior management.
6.2.1Mobile device policyPolicies for portable/mobile devices, including personal devices, used to access, process, or store business information
6.2.2Remote work policyAny policies that govern remote work, including how remote employees treat confidential information, working hours and schedules, use of equipment (including remote access and VPN policies/procedures), ethics, performance measurement, etc.
7.1ISMS ResourcesAny documents concerning resources dedicated to maintaining and improving the ISMS, including audit reviews, incident reports, remediation plans, strategy/planning/budgeting documents, management meeting minutes, etc.
7.1.1Employee Screening & Background ChecksBackground check and screening documents, typically maintained and stored by HR
7.2CompetenceISO 27001 requires organization to “retain documented information as evidence of competence.” For example, evidence of security awareness training for personnel directly involved with maintaining the ISMS
7.2.1Management Statement of ResponsibilitiesManagement must release a formal statement to employees describing their responsibilities to comply with infromation security policies and procedures. This could be an email or entry in an employee handbook.
7.2.3Disciplinary ActionsAlong with the Management Statement of Responsibilities, a formal disciplinary process for noncompliance with infosec policies and procedures is required. If there have been any instances of disciplinary actions against IS breaches please provide evidence of disciplinary actions taken such as access termination, documented warnings, and/or other forms of reprimanding.
7.3.1Termination Policy and ProceduresPolicies and procedures for employment termination must consider information security, including how to retrieve company assets, including information, access controls, etc. This policy should also describe any ongoing responsibilities to the security of the company and its customers. If the ISMS has any termination tickets and/or exit checklists to support the employment termination process that could be provided as well.
7.3Employee Security Awareness TrainingInclude any security awareness training materials, including posters, presentations, leaflets, quizzes, training course certificates, attendance records, etc.
7.4CommunicationInclude any communications made about the ISMS, such as a certification announcement. Document any processes or policies made around what needs to be communicated, when, and to whom.
7.5.1General documentationHow will you organize, review, and update your ISMS documentation? A spreadsheet like this one can be used as evidence, or a separate document management system.
7.5.2Templates for creating and updating documentationAll ISMS documents should have templates that include elements like version control, revision history, management approval, etc.
7.5.3Documentation controlAny reports about who has access to ISMS documents and the type of access they have (view/edit), classification type, etc.
8.1Operational planning and control proceduresISO 27001 requires organizations to maintain documentation that information security processes are being followed and carried out as they were intended. This can include budgets demonstrating the appropriate resources are being dedicating to maintaining and improving the ISMS, compliance activities relating to internal audits, incident reports, vulnerability assessments, penetration test reports, etc.
8.1.1Information Asset InventoryInventory list of all information assets and systems
8.1.2Information Asset OwnersThe inventory list should include a column specifying an owner for each information asset
8.1.3Acceptable Use PolicyDocument a set of rules that a user must agree to before gaining access to the corporate network.
8.1.4Return of Information AssetsAs part of the termination process, define how you will retrieve corporate information, media, paperwork, access keys/passes, etc. Exit checklist can be provided here
8.2Risk assessment resultsPeriodic risk assessment reports, updated risk registers, meeting minutes where business risks were discussed — any documentation that shows your auditor that your processes yield useful information concerning business risks.
8.2.1, 8.2.2, 8.2.3Data Classification and HandlingData classification policy used to categorize information based on sensitivity level and define how each type of data should be classified, labeled, and handled.
8.3Risk treatment resultsRisk treatment plan, penetration test reports, vulnerability assessments, internal audit reports, management reviews, control test reports
8.3.1, 8.3.2, 8.3.3Media handling, transfer, and disposalPolicy for preventing unauthorized disclosure, modification, removal, or destruction of information stored on media devices. Any evidence or tickets for media handling, transfer, and disposal.
9.1MetricsAny security metrics reports, dashboards, pressentations, emails, etc. that show the efficacy of the ISMS is being measured and those metrics are being acted upon.
9.1.1, 9.1.2Access Control Policy and Network AccessPolicy that sets rules for who can access what data or resources at an organization.
9.2ISMS Internal AuditsInternal audit reports, nonconformity reports and remediation timelines, audit calendars.
9.2.1, 9.2.2, 9.2.3User registration, access provisioning, and user managementPolicy that defines the accounts and access that are authorized to users or automatically provisioned based on the user’s role. Evidence of access provisioning (access approvals, tickets, emails)
9.2.4Password management policy and processPolicy that provides guidelines for password standards and requirements. This includes the creating, changing, and communicating of secure passwords.
9.2.5, 9.2.6Access rights reviews and adjustmentsProcedures for regularly reviewing user access rights for all employees and vendors. Evidence of access reviews.
9.3ISMS Management ReviewsManagement review reports, calendars and plans for management reviews, recommendations.
9.3.1, 9.4.3Password security and managementPolicy around using strong passwords, keeping passwords confidential, as well as the use of any password managers or vaults.
9.4.1, 9.4.2Information access controls, source code accessPolicies or documentation around who can access information assets and source code and under what circumstances, along with access logs, firewalls, and any change management records for updates to access rights.
9.4.5Multi-factor authenticationPolicy and configurations that establish strong authentication for all users with access to information systems, while ensuring ease of adoption and use.
9.4.4Use of privileged utilitiesPolicy that provisions the use of applications that require a level of system or administrative privilege to operate (such as an anti-virus application).
10.1Nonconformities and remediationsList of nonconformities and remediation plans, including owners and timelines. Incident reports, audit findings, or complaints may also be used as documentation. Your auditor needs to see that nonconformities are being identified and resolved.
10.1.1, 10.1.2Cryptography policy and key managementPolicy and configurations for securing data by making it unreadable for all parties who do not know the decryption key.
10.2Continuous improvementAny documents that show continuous improvement of the ISMS. This can include internal/extnernal audit reports, incident reports, corrective action, ISMS planning, management meeting minutes etc.
11.1.1, 11.1.2, 11.1.3Physical security and access controlsEvidence that the organization’s physical locations are secure from unauthorized access. This can include photographs of the property including security systems, locks, signs, fences, emergency exits, etc. This can also include visitor/patrol logs or badge/access lists.
11.1.4Environmental security and protectionAny documents that detail geographical threats to organization facilities, such as fault lines, landslides, flood planes, highway overpasses, etc.
11.1.6Workplace safetyPolicies about accessing secure zones such as loading bays or testing facilities. Evidence can include photographs of “Visitors must be accompanied at all times” signs, CCTV footage, card access logs, visitor logs, etc.
11.2.1, 11.2.2, 11.2.3Equipment securityEvidence that confirms that all IT equipment, data storage, server facilities, filing cabinets, archives, etc. are adequately secure. Photographs of the area including locks, fuseboxes, CCTV, backup generators, smoke alarms, seismic racks, etc.
11.2.4Facilities and equipment maintenancePolicies and procedures for maintaining organization facilities and equipment, including inspection reports, maintenance logs, repair invoices/tickets, test reports, etc.
11.2.5, 11.2.6, 11.2.8Removal of assets, security of off-site assets and unattended equipmentPolicies that govern who can remove on-site IT equipment or media, under what circumstances, and how assets should be secured while off-site.
11.2.7Secure re-use and removal of information assetsPolicies and/or procedures for archiving and erasing stored data.
11.2.9Clear desk and screen policyEvidence can include documented policies, photographs, and screen-lock timeouts/configurations.
12.1.1, 12.1.2, 12.1.3Change and capacity management, and operating proceduresExamples include logging and monitoring, automatic patching, version control, backups and archives, change approvals/tickets.
12.1.4, 12.1.5Secure development practices, including separation of development, testing, and productionPolicies and procedures that state how your organization creates a secure coding environment. Examples include version management or system library logs, code review reports, and internal audits.
12.2.1Antivirus softwareEvidence to prove that your organization has sufficient malware controls. Examples include contracts, software installation records, employee awareness training, program updates, malware incident reports, and malware scans.
12.3.1Data backupsPolicy that describes when and how your organization will backup sensitive data. Other evidence can include backup logs and schedules, and restoration test reports.
12.4.1, 12.4.2, 12.4.3Event, audit, and operator logs, log securityA healthy security program should generate events and activities that are recorded in logs, alerts, and incident response activity.
12.4.4Clock syncsEvidence that network and systems architecture are periodically synchronized to a central system clock. This should include policies and configurations of the ISMS being synchronised to a single reference time source. 
12.5.1, 12.6.2Software installations and restricted softwareExamples include a list of apps that are approved for use, restrictions for software updates, installation records.
12.6.1Technical vulnerability managementA vulnerability management policy establishes rules for reviewing, evaluating, and verifying system updates to mitigate vulnerabilities in the system environment. Evidence can include vulnerability scans, event logs, change logs, patch logs, etc.
12.7.1Systems audit controlsInternal/external audit reports, planned or scoped audits, details of any ongoing audit functions.
13.1.1, 13.1.2, 13.1.3Network and network service securityEvidence can include information on routers, firewalls, VPNs, intra/extra/subnets, cloud services, wireless networks, IDS/IPS, etc.
13.2.1, 13.2.2, 13.2.3Information exchange and transfer agreementsPolicies and procedures for communicating sensitive information with third parties (press and media, business partners and suppliers, customers, financial partners, insurance companies, auditors, etc.). If the ISMS has agreed to any ISAs, MOUs, or contracts with third parties those can be provided as well.
13.2.4Use of NDAsEvidence can include acutal NDAs used as well as confidentiality clauses in contracts and agreements.
14.1.1, 14.1.2, 14.1.3, 14.2.1, 14.2.5, 14.2.8, 14.3.1, 14.2.9System security requirements, transaction security, secure development, security testing, test data securityEvidence of how the organization identifies, evaluates, and addresses risk throughout the software development lifecycle. Examples include security testing procedures, penetration test reports, vulnerability scans, test data and results, alarms, fraud controls, etc.
14.2.2, 14.2.3, 14.2.4Change controlsChange management policies, change logs, records, tickets, etc.
14.2.7Outsourcing developmentIf applicable, any policies or guidelines around outsourcing development to third parties such as contractors or commercial developers. This can include contracts, specifications and standards, progress monitoring, testing and remediation, etc.
15.1.1, 15.1.2, 15.1.3, 15.2.2Supplier and third-party service policiesEvidence can include policies around selecting and using third-party vendors, including agreements, selection criteria, reviews, business continuity strategies, risk assessments and/or treatments, etc.
16.1.1, 16.1.2, 16.1.3, 16.1.4, 16.1.5, 16.1.6, 16.1.7Incident response, reporting, and managementIncident response procedures, including roles and responsibilities, communication plans, records and logs, alerts, post-incident reports, etc.
17.1.1, 17.1.2, 17.1.3, 17.2.1Planning, implementing, and verifying information security continuityInformation security and business continuity policies and procedures including Business Continuity Plan (BCP) and/or Disaster Recovery Plan (DRP)
18.1.1, 18.1.2, 18.1.3, 18.1.4, 18.1.5Identifying legal, regulatory, and compliance obligationsDocumentation that shows the organization has proactively identified all applicable legal, regulatory, and compliance requirements. Evidence can include customer contracts, applicable laws and regulations, etc.
18.2.1, 18.2.2Information security and policy reviewsEvidence that security processes and policies are reviewed internally on a periodic basis.
18.2.3Technical complianceVulnerability scans or penetration test reports, internal audit reports, etc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s