ISMS CHECKLIST

Requirement Status Interpretation Notes

Mandatory documentation and records

The ISMS scope clarifies the boundaries of the certified ISMS in
relation to the context or business situation of the organization
(e.g. certain business units, sites or departments), and its
information risks and security requirements plus any imposed by
◻ Specified third parties (e.g. laws and regulations plus contractual
4.3 ISMS Scope obligations and often, in a group structure, strategies and policies
◻ In draft
mandated/imposed by HQ). Security must be taken into account
◻ Done whenever information crosses scope boundaries. A high-level
business-driven strategy or vision statement (either made or at
least formally endorsed/signed-off by senior management) is one
way to crystallize both the scope and purpose of the ISMS, and
can be useful for awareness/promotional purposes too.
The information security policy (or policies) lays out and confirm
senior management’s commitment to (a) the organization’s
information security objectives and (b) continuous improvement
◻ Specified of the ISMS … and often much more. Senior management may
5.2 Information prefer to mandate a single, succinct, broad/overarching
security policy ◻ In draft
governance-type policy (formally satisfying the ISO requirement),
◻ Done supported by a suite of detailed information risk, security,
compliance, privacy and other policies, procedures, guidelines
etc. (see A5.1.1) or you may take a different approach.

It is up to you to determine precisely what is appropriate for your

organization using clause 6.1.2 as a guideline plus ISO/IEC 27005
and ISO 31000. The auditors expect a structured and repeatable
process i.e. a documented risk assessment procedure explaining
6.1.2 Information how you identify, analyze (e.g. identify potential consequences
security risk ◻ Specified and probabilities of occurrence), evaluate (e.g. use specified
assessment criteria for risk acceptance) and prioritize your information risks
Process ◻ In draft
(e.g. using risk levels), with periodic reviews/updates to reflect
documentatio ◻ Done gradual changes plus ad hoc reviews/updates in response to
n step-changes in your information risks. You should also make
available relevant reports, entries in your risk register with risk
descriptions, identified risk owners etc. and metrics to
demonstrate its operation.
Requirement Status Interpretation Notes
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
6.1.3 Information A and ISO/IEDC 27002, plus any alternative/supplementary
security risk ◻ Specified sources such as NIST SP800-53, ISO 31000, ISO/IEC 20000, ISO
treatment ◻ In draft 22301 and 22313, IT-Grundschutz, the ISF Standard of Good
(d) Statement of Practice, assorted privacy laws and principles etc. Clarify whether
◻ Done
Applicability 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.

Again it is up to you to determine precisely what is appropriate

for your organization, using clause 6.1.3 plus guidance from
ISO/IEC 27005 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
6.1.3 Information
◻ Specified information risk, or an integral part of enterprise risk
security risk
treatment management etc. Typical evidence includes a written policy
◻ In draft
Risk treatment and/or procedure for consistently deciding on and implementing
◻ Done appropriate information risk treatments. Convince the auditors
process
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

The ISO requirement to “retain documented information on the

information security objectives” is vague too, so once more you
6.2 Information ◻ Specified have some latitude. A good approach is to start with the
security
objectives and ◻ In draft organization’s high level business objectives, deriving information
plans ◻ Done risk and security objectives from them. These can be supported
by lower level control objectives and controls and metrics (6.2b).
Requirement Status Interpretation Notes
You know the drill: interpret the vague requirement to “retain
documented information as evidence of competence” as you see
fit – for example, you may rely on HR records documenting the
relevant experience, skills, qualifications, training courses etc. just
for the core ISMS people within your information risk and security
management function, or extend the net to include all the
information risk, security, governance, privacy, business
continuity and compliance-related people (and possibly others
◻ Specified such as security awareness and training professionals,
departmental information security/privacy reps,
7.2 Competence ◻ In draft
business/security analysts, penetration testers etc., perhaps even
◻ Done consultants, contractors and advisors). In time you might develop
a skills matrix (relating people to rôles according to their skill sets
etc.), maybe even a RASCI table (showing, for each key
information risk and security-related process or decision, which
functions, rôles or people are Responsible, Accountable,
Supportive, Consulted or Informed). We recommend keeping it
simple, for certification purposes. You can always do more later
on.

Make what you will of the requirement to “keep documented

information to the extent necessary to have confidence that the
processes have been carried out as planned”. Generally speaking,
this implies management information concerning the ISMS such
as budgets and headcounts and progress reports containing
relevant metrics, information risk and security strategies, plans,
policies, procedures and guidelines, plus related compliance
activities to check/measure, enforce and reinforce compliance,
8.1 Operational ◻ Specified plus records generated by or information arising from the
planning and procedures/activities, and other stuff such as post incident
control ◻ In draft
reports, security test reports, security product evaluations,
Procedures ◻ Done vulnerability assessments, business impact assessments,
preventive or corrective actions, security architectures and
designs … much of which we have already noted or is covered
under Annex A. Although the details will vary between
organizations, it 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.
Requirement Status Interpretation Notes
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
8.2 Risk ◻ Specified risk inventories/catalogs etc. You may have meeting
assessment ◻ In draft notices/invitations, minutes of meetings, risk workshop reports,
results rough notes from discussions arising, formal memoranda, emails
◻ Done
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.

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
8.3 Risk ◻ Specified capital expenditure, metrics showing a reduction in the
treatment ◻ In draft frequency and/or severity of the corresponding incidents etc.,
results management review and audit reports, emails from
◻ Done
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!).

The ISMS generates various metrics that are used to monitor and
drive information risks, controls and the ISMS itself in the
intended direction. Evidence here includes security metrics in
◻ Specified reports, systems, dashboards, presentations etc., plus proof that
9.1 Metrics ◻ In draft the metrics are being duly noted and acted upon e.g. memos,
◻ Done emails or rough notes expressing concern about adverse trends
or thanks for positive trends; comments scribbled on printed
reports; action plans; minutes of meetings etc.

ISMS internal audit reports are the obvious evidence here,

9.2 ISMS internal ◻ Specified
documenting the main audit findings, conclusions and
audits
◻ In draft recommendations, often in the form of
Requirement Status Interpretation Notes
Nonconformity/Corrective Action Reports. Supporting evidence
may include audit programs or plans or calendars, budgets and
auditor man-day allocations, audit scopes, audit working paper
files with detailed audit findings and evidence (such as completed
◻ Done checklists), audit recommendations, agreed action plans and
closure notes etc. The certification auditors may want to
interview/chat to the ISMS auditors about the ISMS and/or issues
raised in their reports.

ISMS management review reports, obviously, perhaps also

calendars/plans, budgets, scopes, working papers with evidence,
9.3 ISMS ◻ Specified recommendations, action plans, closure notes etc. The
management ◻ In draft certification auditors may want to interview/chat to relevant Top
reviews Management and managers about the ISMS and/or issues raised
◻ Done
in their reports.

‘Nonconformities’ are (partially or wholly) unsatisfied

requirements, including those within ISO/IEC 27001, plus
strategies, policies, procedures, guidelines, laws, regulations and
contracts. They may be documented in the form of issues,
events, incidents, audit and review findings, complaints, or simply
as “nonconformities” (e.g. on a Nonconformity/Corrective Action
Report NCAR form). The certification auditors need to be
10.1
◻ Specified convinced that nonconformities are being routinely and
Nonconformiti
systematically identified, raised/reported, addressed and
es and ◻ In draft
corrective resolved, by reviewing (their sample of) relevant documentary
actions ◻ Done evidence. Make it easier for them by maintaining a register or
index of nonconformities, along with the neatly-filed evidence of
actions undertaken in response to the nonconformities such as:
root-cause analysis; reaction to the nonconformity such as
immediate containment or correction; final results of the
corrective action including review of its effectiveness and
completion/closure/sign-off for the nonconformity.
Requirement Status Interpretation Notes

Additional documentation, records and evidence

Main body of ISO/IEC 27001
Identify yourself. Use a diagram and show an organizational chart
as to where your team and operation resides and who are the
Top Management stake holders. Represent both the technical
team and the business team

The documented process or procedure of holding a strategy

◻ Specified meeting (or similar) where internal and external issues relevant
4.1 Organization to the ISMS are discussed.
and context ◻ In draft
◻ Done Minutes of a strategy meeting (or similar) where management
discussed various internal and external issues that were relevant
to the ISMS – preferably within the past year.

While the minutes will provide evidence of the process being

followed, the process itself should be documented.

Some sort of list of stakeholders in the ISMS, updated

periodically (implying a procedure to formulate and maintain the
list). This may include or reference lists of laws, regulations,
◻ Specified contracts, agreements etc. that are relevant i.e. concern risks to
4.2 Interested and requirements for the security/protection/control of
parties ◻ In draft
information. Internal corporate stakeholders in the ISMS should
◻ Done also be identified, including not just those who direct and oversee
the ISMS but also those who depend on its correct operation
(‘customers’ of the ISMS).

Your ISO/IEC 27001 compliance certificate from an accredited

auditor is or will be the ultimate evidence of this! Meanwhile,
◻ Specified your ISMS has a raft of documented policies, procedures,
guidelines etc. These are best kept in order, under control and
4.4 ISMS ◻ In draft
available to all who need them, for example on an intranet site,
◻ Done Document Management System or Governance Risk Compliance
system.

5.1 Leadership Evidence of management commitment to the ISMS may include

◻ Specified
their obvious interest and active involvement in the certification
◻ In draft audit and other important ISMS activities (e.g. risk workshops),
◻ Done adequate budgets, approval of various formal documents
Requirement Status Interpretation Notes
(including budgets, expenditure and overspend/contingency),
explicit reference to information risk and security in strategies
and plans etc. Communications from senior management to all
staff are excellent evidence (see also 7.4 below), for example
when the certification efforts are launched (announcing the
strategy, explaining key targets, stating who leads the effort and
directing everyone to support the ISMS). Further
communications should be issued for example about the
certification audits, award of the certificate etc., reinforcing the
ongoing efforts to use, maintain and improve the ISMS. The
seniority level or rank of the most senior information risk and
security person (e.g. CISO or ISM), and the breadth of scope of
the ISMS, are also strong indications of how seriously
management takes this.

The level or rank of the most senior information risk and security
person (e.g. CISO or ISM) relative to other
departments/functions, and the breadth of scope of the ISMS
5.3 Rôles and ◻ Specified (e.g. buried within IT, limited to specific business units or
responsibilitie ◻ In draft organization-wide), are strong indications of how seriously
s management takes this. The governance arrangements are
◻ Done
generally documented in organization charts showing reporting
lines, rôle/job descriptions, vacancy notices etc.

This is a high-level requirement that the ISMS helps the

organization manage its information risks and security controls
6.1.1 Actions to ◻ Specified systematically, on an ongoing basis. Evidence may include
address risks strategy documents, vision statements, minutes of ISMS
and ◻ In draft
management meetings, corrective actions Done, management
opportunities ◻ Done and audit recommendations actioned, improving metrics etc. In
time, the continued success of the ISMS should speak for itself.

7.1 Resources ISMS resources are primarily people (Full Time Equivalents,
◻ Specified
headcount or list of permanent employees plus consultants,
◻ In draft contractors, advisors, interns, temps etc.) and budgets. Note that
◻ Done the true expenses/costs of information risk and security, and the
benefits, are distributed widely throughout the organization
across all the activities that involve information: however, it is
much simpler (and usually sufficient) to account purely for the
Information Risk and Security Management function operating
Requirement Status Interpretation Notes
and managing the ISMS. Talk to your finance department about
which accounting codes and reports to use.

Evidence for the security awareness activities includes any

relevant procedures and standards, awareness materials
(posters, presentations, briefings, web pages, leaflets, quizzes,
◻ Specified competitions, training course notes, lists of rewards/prizes issued
7.3 Awareness ◻ In draft etc.) and metrics (e.g. records of attendance and feedback scores
◻ Done from awareness events, awareness survey and test results, and
details of the ongoing investments in security awareness and
training).

The requirement is very vague here. Think about what you

◻ Specified communicate regarding the ISMS, to whom, when and how, and
7.4
gather relevant evidence about it – emails, notices, reports,
Communicatio ◻ In draft
n metrics etc. Document the internal communications processes as
◻ Done well as collect evidence that shows them in operation.

This very checklist, once completed and supported by the

referenced documentation and records, is a simple way to
demonstrate to the auditors the nature, breadth, volume and
quality of information concerning and generated by your ISMS. In
addition to using this as part of your preparation for certification,
7.5.1 General ◻ Specified you might like to maintain it indefinitely as a living record of your
This doc!
documentatio ◻ In draft ISMS documentation, or perhaps migrate everything to a
n Document Management System with the functionality to track
◻ Done
and report on all the documentation. ISMS documents need to
be reviewed and updated periodically, with the reviews, changes
and re-authorization being noted within in the documents
themselves and/or in the DMS.

A set of document templates for all the ISMS documents is a

◻ Specified simple way to make sure they all have the standard document or
7.5.2 Creating
version control information (such as the revision history, and any
and updating ◻ In draft
docs authorizations or mandates), as well as making them more
◻ Done consistent.

7.5.3 Control of Document management systems and webservers can generate

◻ Specified
docs reports of access rights, document status etc. for policies,
◻ In draft procedures and guidelines etc. Emails, management reports,
◻ Done review and audit reports, metrics reports etc. generally state their
Requirement Status Interpretation Notes
own distribution on the cover, or may use classification rules or
managed distribution lists.

Documentary evidence for continual improvement of the ISMS

◻ Specified includes the reports of reviews, audits, incidents, corrective
10.2 Continual
improvement ◻ In draft actions, ISMS strategy/planning and management meetings plus
◻ Done assorted metrics demonstrating positive trends (hopefully!).

Annex A - Further guidance on these controls is provided in ISO/IEC 27002:2013 and other standards

In addition to the main information security policy (5.2), the

organization is expected to have written policies addressing
specific areas of information security. Examples (not a
A.5.1.1 mandatory list) are provided in ISO 27002:2013 clause 5.1.1, and
Information 6.2.1. These need not be separate documents and may include
security pre-existing policies, for example a data protection or privacy
policies policy.
◻ Specified
A.5.1.2 Review
the policies ◻ In draft Evidence of policy reviews can be a simple diary showing the
A.6.2.1 Mobile ◻ Done reviews and/or review and approval dates on the policies
device policy themselves (standard document control information).
A.6.2.2
There should be written information security policies for
Teleworking
portable/mobile ICT devices including personal devices used to
access, process or store business information (BYOD), plus
teleworking.

A.6.1.1 Information risk and security rôles and responsibilities are

◻ Specified
Information normally documented in job descriptions, vacancy notices,
security roles ◻ In draft policies, employee handbooks, contracts of employment,
and ◻ Done service contracts etc., particularly for the ‘obvious’ jobs such as
responsibilitie CISOs, Information Security Managers and Security Guards.
s
Another/complementary approach is to draw up a matrix with
A.6.1.2
jobs/rôles on one axis and responsibilities on the other, or a
Segregation of
duties RASCI chart (there’s a template in the ISO27 Toolkit). Mutually
exclusive rôles should be identified as such (e.g. separating the
A.7.1.2 Terms
and conditions definition, implementation, allocation and review/audit of access
of rights for important IT systems). Depending on the situation,
employment don’t forget about contractors, consultants, temps, interns,
facilities/maintenance workers, home workers and (perhaps)
privileged vendor support people working on company business
Requirement Status Interpretation Notes
on- or off-site [your organization may specify information security
requirements in contracts with the vendors, who in turn may
specify information security rôles and responsibilities in their
employment contracts].

Contact details, business cards, membership certificates, diaries

of meetings etc. can provide evidence of professional contacts,
particularly for information risk, security and compliance
A.6.1.3 Contact
◻ Specified specialists. Is anyone in touch with CERT, professional bodies
with
authorities such as ISACA, (ISC)2 and ISSA, industry regulators etc.? Prove it!
◻ In draft
A.6.1.4 Contact Valid contact details embedded within incident response,
◻ Done business continuity and disaster recovery plans is further
with SIGs
evidence of this control, along with notes or reports from
previous incidents concerning the contacts made.

◻ Specified Project management manuals, methods, policies, procedures,

A.6.1.5 Infosec in guidelines, forms etc. should include relevant information risk
projects ◻ In draft
and security activities.
◻ Done
Records of identity and background checks are normally
maintained by HR, Security etc. as part of employees’ personnel
info. The checks may be done routinely prior to employment
◻ Specified (e.g. checking/copying passports or other official photo-ID at
A.7.1.1 Screening ◻ In draft interview), periodically for trusted rôles, on promotion into such
◻ Done rôles, when personnel incidents occur/concerns are raised, and
perhaps randomly as a deterrent. Don’t forget about contractors,
consultants, interns, advisors, temps etc.

A formal management statement to employees mandating their

compliance with the information security policies and
A.7.2.1 ◻ Specified procedures. This may go out as an email or memo, be re-stated
Management in the front of the security policy manual and on the intranet site
responsibilitie ◻ In draft
where policies and procedures are made available, and perhaps
s ◻ Done included and explained in security training and awareness
materials.

A.7.2.2 Security Your security awareness and training materials should

◻ Specified
awareness demonstrate that an effective, lively, ongoing awareness program
and training ◻ In draft is in operation. Examples: awareness posters, briefings, slide
◻ Done decks for seminars and courses, guidelines, tests and quizzes, plus
metrics (see 7.3 above). Regular or ad hoc awareness updates
Requirement Status Interpretation Notes
are required to pick up on changes, emerging risks etc. and
maintain awareness levels and skills. Professionals/specialists
with significant responsibilities in information risk, security,
governance, compliance etc. may need suitable, in-depth training
(e.g. PCI-DSS for those handling credit cards, HIPAA for those
handling patient information, and privacy laws and regulations for
those handing personal information). Keep an awareness diary
and rolling plan and update employee training records.

A formal disciplinary process may be part of your HR

procedures / staff handbook and cited in employment/service
A.7.2.3 ◻ Specified contracts etc. Records of disciplinary actions undertaken should
Disciplinary ◻ In draft prove that the process is being followed but may be too
process confidential to disclose in full, especially for any ongoing disputes
◻ Done
or legal cases.

Policies, procedures, guidelines and forms supporting the

termination process should incorporate information security
A.7.3.1 elements such as retrieving corporate information and other
Termination ◻ Specified assets (e.g. IT systems, media, paperwork, keys, passes) from
process ◻ In draft them, and explicitly reminding departing employees of their
A.8.1.4 Return of ongoing security, privacy and other obligations, both legal and
◻ Done
assets ethical, towards the organization, its customers, their colleagues
etc.

An inventory (or list or database …) of information assets, IT

A.8.1.1 Asset ◻ Specified
inventory systems etc. including details (names and/or rôles) of their
◻ In draft owners, typically managed within IT inventory or management
A.8.1.2 Asset
owners ◻ Done applications.

◻ Specified Typically documented as an acceptable use policy, along with

A.8.1.3
procedures and other guidance e.g. a code of practice or
Acceptable ◻ In draft
use employee rulebook.
◻ Done
A.8.2.1 Typically documented as an information classification policy,
◻ Specified
Information along with procedures and other guidance for handling
classification ◻ In draft information according to its classification. A selection of duly
A.8.2.2 ◻ Done marked and protected information assets demonstrates that the
Classification policy is in operation.
labelling
A.8.2.3 Handling
Requirement Status Interpretation Notes

of assets
Typically documented in one or more security policies supported
by procedures and guidelines concerning portable storage media
(USB sticks, portable hard drives, tapes, paperwork etc. plus
A.8.3.1 Media portable devices, briefcases etc. containing media) - physical
management access control and protection, encryption, safe storage, labeling,
◻ Specified
A.8.3.2 Media chain of custody records (e.g. details and signatures as media are
disposal ◻ In draft transported by couriers) etc.
A.8.3.3 Media ◻ Done
Evidence of media transport and disposal may include receipts,
transfer
confirmations and/or disposal certificates from courier/transport
and disposal service providers, whether performed in-house or by
competent commercial companies (preferably under contract).

Typically documented as one or more access control policies

(possibly one overall policy [supported by something more
specific for each major IT system, network or type of information
A.9.1.1 Access ◻ Specified asset such as an access matrix showing access permitted by
control policy various rôles to various assets, functions etc.) along with
A9.1.2 Network ◻ In draft
procedures for secure logon and other guidance concerning
access ◻ Done controlled access to information (networks, systems, applications,
data, databases, contracts, paperwork, knowledge etc.) such as
guidelines on passwords, VPNs, firewalls etc.

Working records from Security Admin typically include Done and

A9.2.1 User actioned access request forms plus authorized signatory lists,
registration ◻ Specified logs and reports from automated access management systems,
A9.2.2 User ◻ In draft change authorizations, information exchanged with HR and
access Procurement (e.g. monthly lists of joiners and leavers,
◻ Done
provisioning consultants/contractors, temps) etc.

Details of special arrangements to control privileged accounts

(e.g. ROOT and auditor accounts) and privileged
A9.2.3 Privileged functions/utilities (e.g. system, security and database
user ◻ Specified administration) especially on high-risk systems, firewalls, log
management management and intrusion detection systems, databases or other
A9.4.4 Use of ◻ In draft
valuable/vulnerable information – typically policies, procedures
privileged ◻ Done and guidelines with operational records demonstrating that the
utilities processes are working properly and that changes to privileged
accounts are reviewed and controlled.
Requirement Status Interpretation Notes
Policies and procedures for creating, communicating and
◻ Specified changing passwords, PIN codes, crypto keys, physical keys etc.
A9.2.4 Password with operational records from Security Admin, access
management ◻ In draft
management systems etc. demonstrating that the processes are
◻ Done working properly.

A9.2.5 Access Policies, procedures and notes or reports arising from periodic/ad
rights reviews ◻ Specified hoc reviews, reconciliation and re-authorization of access rights
A9.2.6 Access ◻ In draft including evidence that inappropriate rights have been identified,
rights considered and addressed (possibly incident or change records).
◻ Done
adjustment
A9.3.1 Password ◻ Specified Policies, procedures and guidelines concerning the choice and
security enforcement of strong passwords, password secrecy, password
A9.4.3 Password ◻ In draft
vaults, password changes etc.
management ◻ Done
Procedures for restricting access to information and applications
A9.4.1 ◻ Specified in line with the classification and handling rules set out in A8.2,
Information plus records of their operation such as access reports from IT
access ◻ In draft
systems, databases, firewalls etc., change management records
restriction ◻ Done for significant access right changes etc.

Policies, standards, procedures, technical architectures/designs

etc. concerning multi-factor authentication or similar
◻ Specified arrangements to strengthen identification and authentication and
A9.4.2 Strong access controls for high-risk systems, privileged functions etc.
authentication ◻ In draft
e.g. procedures for issuing, using, retaining, replacing and
◻ Done recovering security tokens/fobs, digital certificates, access-all-
area passes, master keys etc.

◻ Specified Policies, procedures, guidelines and evidence concerning

A9.4.5 Source controlled access to program source code – typically available
code access ◻ In draft
from source code library management systems.
◻ Done
Cryptography policy, standards, policies and guidelines
A10.1.1 Crypto ◻ Specifi
policy concerning algorithms and key lengths for encryption and
ed
◻ In draft authentication, key management, PKI (e.g. Certification Practice
A10.1.2 Key
management ◻ Done Statement), digital certificates, digital signatures etc.

A11.1.1 Physical Evidence here is plain to see, or conspicuous by its absence!

◻ Specified
perimeter Controls and vulnerabilities can be substantiated through a
◻ In draft physical site inspection (walk-through or physical penetration
A11.1.2 Physical
Requirement Status Interpretation Notes
test), photographing signs, fences, barriers, locks, chains,
turnstiles, gates, emergency exits, loading ramps, guard houses,
key cabinets etc., plus discussion with Site Security/guards and
Facilities Management.

Some organizations regularly inspect their physical security

entry control arrangements, generating review reports, diary entries, incident
A11.1.3 Secure reports, maintenance logs etc.
offices/facilitie ◻ Done
s If security guarding is outsourced, contracts plus security
procedures etc. should clarify the expected controls while patrol
logs etc. plus inspection should confirm that they are operating
correctly. Other evidence might include visitors’ books, logs for
access cards or keys issued to contractors, temps, guards,
maintenance engineers etc.

Maps, weather and news reports, local council records etc. may
indicate physical geographical/topological threats to the area
◻ Specified containing corporate facilities (e.g. flood plains, fault lines,
A11.1.4
sinkholes/caves, landslips, tornadoes/hurricanes, ice, erosion,
Environmental ◻ In draft
protection major flight paths, highway over-passes or off-ramps, war zones
◻ Done …). Physical inspection and photography provides further
evidence.

Policies, procedures, guidelines, notices etc. concerning access to

secure zones (e.g. “No lone working” and “Visitors must be
A11.1.5 Working accompanied at all times”) and delivery ramps/loading
in secure ◻ Specified bays/tradesmen’s entrances. Other evidence includes security
areas guard patrol and incident response procedures, CCTV footage,
A11.1.6 ◻ In draft
card access system reports, visitor books and records associated
Delivery/loadi ◻ Done with staff and visitor passes, keys etc. plus physical inspection and
ng bays photographs (if permitted!) of the access controls (e.g. locks,
barriers, slab-to-slab partitions, intruder alarms, fire exits).

A11.2.1 Site maps, physical inspection and photography should confirm

◻ Specified
Equipment that IT equipment, storage media, computer facilities, paper
◻ In draft files/filing cabinets, archives/store rooms, videoconferencing
A11.2.2
Supporting ◻ Done facilities etc. are sited and stored in adequately secure areas
utilities (e.g. with barriers and locks, safes, screens not visible from public
A11.2.3 Secure land) with high-grade utilities (e.g. power feeds and distribution,
cabling air conditioning) and controls (e.g. fuses, monitoring and alarms
Requirement Status Interpretation Notes
for intruders, fire/smoke, water and power issues, CCTV, UPS
with battery and generator backup) as necessary to provide
appropriate environmental protection (A11.1.4).

Policies, procedures, guidelines and records (such as installation

◻ Specified inspections, maintenance logs, test reports and fire certificates)
A11.2.4
Maintenance ◻ In draft should confirm that the facilities operations, management,
◻ Done security and maintenance activities are adequate.

Policies, procedures, guidelines and records should cover rules

for and authorization of physical removal of IT equipment and
storage media from storage or from site e.g. portable IT devices,
security tokens, keys, tapes and disks, paper files,
equipment/media sent for repair or archival. It is possible to
◻ Specified reconcile (a sample of) the current asset removal records against
A11.2.5 Removal
of assets ◻ In draft reality e.g. by confirming that they were properly authorized, that
◻ Done the employees are still employed (!) and that they can produce
the assets for inspection, and that all valuable information assets
can be accounted for: such a stock-check should probably be a
routine activity, so there should be notes, reports, incident
records etc.

Policies, procedures and guidelines should specify protection of

information on smartphones, laptops, tablets, USB sticks,
A11.2.6 Security portable hard drives, valuable papers, knowledge workers etc.
of off-site ◻ Specified when off-site e.g. home office security, in vehicles especially
assets public transport, when staying at hotels, conferences etc., and
A11.2.8 ◻ In draft
working-from-home/teleworking/remote network access
Unattended ◻ Done e.g. VPNs. Physical and logical controls may be required
equipment e.g. firesafes, encryption, health and safety. Note: BYOD should
be covered similarly to corporate stuff.

Policies, procedures and guidelines for secure erasure of storage

A11.2.7 Secure ◻ Specified media or use of strong encryption (with appropriate key
disposal and ◻ In draft management) may include secure archival prior to disposal/re-
re-use use.
◻ Done

A11.2.9 Clear Compliance with clear-desk clear-screen policies can simply be

◻ Specified
desks and assessed by workplace inspections during or outside normal
screens ◻ In draft working hours … which might be routine for the security guards,
◻ Done in which case there should be reports and incident logs. Screen-
Requirement Status Interpretation Notes
lock timeouts with password reactivation may be set by Windows
domain policies or local configurations – check the approach and
records.

There should be a suitable range of information risk and security-

related procedures plus the associated policies, guidelines,
awareness and training materials, checklists, forms etc., all of
A12.1.1
which should be of good quality, readable, authorized, controlled,
Operating
procedures ◻ Specified disseminated, used (generating records) and maintained (yes, this
is another prod about the documentation requirement in the
A12.1.2 Change ◻ In draft
management main body section 7.5). Examples: installation and configuration
◻ Done of IT systems; backups and archives; job scheduling; errors,
A12.1.3 Capacity
management alarms and alerts, plus logging and monitoring; patching, change
management and version control; capacity and performance
management.

Policies, procedures and guidelines should clarify how assorted

specifications, source code, executables, libraries, system
A12.1.4 documentation, data, people etc. for IT development, test,
Segregation of
◻ Specified production and support environments are distinguished, kept
dev, test and
prod separate and controlled, including how they are migrated,
◻ In draft
A14.2.6 Secure checked in/out or promoted between them. Records (e.g. logs
◻ Done from the software library or version management system, and
dev
environment reports from reviews, reconciliations or audits) should
demonstrate that things are working correctly.

To prove that the organization has designed, implemented,

checked, used, managed and maintained suitable malware
◻ Specified controls, auditors may check policies, procedures, guidelines,
architectures/designs, contracts and records (such as details of
A12.2.1 Antivirus ◻ In draft
malware incidents, antivirus program and signature file update
◻ Done histories, software installation records, and awareness/training
records).

A12.3.1 Backups Valuable information assets (computer data, paperwork and

◻ Specified
knowledge workers!) should be regularly backed up and stored
◻ In draft safely and securely … and must be capable of being restored as
◻ Done and when needed. Evidence may include: backup strategies,
architectures, policies, procedures and guidelines, schedules,
backup management systems and associated records, logs, test
reports etc. Note: don’t forget off-site data (e.g. home/mobile
Requirement Status Interpretation Notes
workers and cloud) and off-site storage (e.g. data and paper
archives).

Various security-related activities, events and incidents should be

routinely recorded in logs, warnings, alarms, alerts, metrics etc.,
both as an historical/evidential/forensic record and to trigger
follow-up actions such as incident response. There is usually a
very large volume and variety of information in this category,
A12.4.1 Event
hence the auditors may only sample-check some, if any. They
logs
◻ Specified may be more interested in the overall strategies (e.g. for log
A12.4.2 Log
management), architecture, systems (e.g. IDS-IPS and SIEM),
security ◻ In draft
policies and procedures, information flows and the associated
A12.4.3 Admin
◻ Done information security controls protecting the logs, systems and
and operator
logs links against accidental damage, equipment failure, ‘loss of signal’
and deliberate interference/manipulation/fraud (e.g. centralized
log management arrangements with strong access controls,
digital signatures, privacy controls, keep-alive/heartbeat timers,
covert monitoring, honey-tokens etc.).

The network/systems architecture should take account of the

need to synchronize or coordinate various system clocks for
◻ Specified various reasons including reliable evidence of the exact time of
A12.4.4 Clock occurrence of incidents and activities (e.g. a policy on using UTC,
synch ◻ In draft
with NTP distributed by time servers referenced to atomic clocks).
◻ Done Note: extreme accuracy or precision is seldom as important as
time coordination, but in some circumstances it is vital.

Software testing, change-approval, version management and

A12.5.1 Software
implementation records may suffice in this area, along with the
installation ◻ Specified policies and procedures (e.g. a library of
A12.6.2
◻ In draft approved/authorized/whitelisted apps; backups taken both
Restricting
software ◻ Done before and after installation; restricted rights to update
installation software). See also A14.2.

A12.6.1 The basic control is a reasonably comprehensive and accurate

◻ Specified
Technical inventory of systems, vulnerabilities etc., plus the associated
vulnerability ◻ In draft policies and procedures to build, maintain, use, manage and
management ◻ Done control it. There should also be A policy and procedure on
patching including roles and responsibilities, plus records or logs
of events, incidents and/or changes arising (e.g. testing and
applying security patches urgently), plus notes concerning
Requirement Status Interpretation Notes
security patches not applied (with reasoned justifications such as
incompatibilities or greater risks arising from patching than from
not patching) and metrics.

Note: there are several other vulnerabilities too (e.g. ignorant or

careless employees, dependencies on unreliable 3 rd-parties, and
badly locater, constructed and maintained buildings) plus threats
and impacts together constituting information risks.

Evidence may include details of audits scoped, planned and

conducted to avoid impacting operational IT services, audit
◻ Specified reports and technical information about any ongoing system
A12.7.1 Systems security/audit functions (e.g. logging/alarming whenever
audit controls ◻ In draft
significant privileges, control bypasses or other such events take
◻ Done place), plus the usual policies and procedures, maybe even
strategies and designs.

Network (security) architecture diagrams, strategies, policies

and procedures are the primary documentation in this area,
demonstrating the organization’s approach to defining and
implementing distinct network security domains or zones
(e.g. WAN-DMZ-LAN, CCTV and card access networks, shop
floor/SCADA/ICS networks, 3G and other public or private
A13.1.1 Network networks, VOIP). Additional information may provide further
security details such as types of routers and firewalls, firewall rulesets,
A13.1.2 Network ◻ Specified VPNs and other layered networks, intranets and extranets, cloud
service ◻ In draft (*aaS), WiFi and other wireless networks, out-of-band
security signaling/control/administration/logging/alarms, IDS/IPS etc. and
◻ Done
A13.1.3 Network possibly records concerning the operation of network security
segregation alarms, incident response, security administration activities
(e.g. network security audits, reviews and penetration tests,
network change management, network capacity and
performance management) and business continuity aspects
(e.g. resilience, redundancy/diverse routing, fail-over,
fallback/recovery).

A13.2.1 Security strategies, policies and procedures concerning the

◻ Specified
Information communication of valuable/sensitive/important information with
exchange ◻ In draft other parties (e.g. Reuters, stock markets, business suppliers,
A13.2.2 Transfer ◻ Done partners and customers, banks and credit-checkers, analysts,
agreements insurers, auditors, authorities, peers, CERT), and the associated
Requirement Status Interpretation Notes
controls (e.g. risk analysis, contracts, addressing, identification
and authentication, encryption, logging and alerting, secure
couriers, delivery confirmation/receipt for nonrepudiation, check-
A13.2.3
Messaging totals and message counts, keep-alive or heartbeat arrangements
with null messages and alerts on link failure, diverse routing,
emergency contacts etc.).

Discrete Non-Disclosure Agreements are the obvious evidence

here, but also confidentiality clauses embedded in various
◻ Specified agreements (e.g. consulting, professional advisors and
A13.2.4 NDAs ◻ In draft employment contracts), and perhaps the associated policies,
◻ Done procedures, guidelines etc. detailing the controls to monitor and
achieve compliance.

Strategies, policies, procedures and guidelines concerning how

information risks are identified, assessed and treated in the
course (throughout the entire lifecycle) of software/systems
A14.1.1 System
security development activities (e.g. structured development methods
requirements with documented risk analysis, security design/selection, secure
A14.1.2 Securing platforms, security services/functions/processes, secure
public apps development/coding, security and performance testing,
A14.1.3 implementation/configuration, post-installation verification,
Transaction system maintenance and management activities, forms etc.)
security concerning the full breadth of application/system security
A14.2.1 Secure ◻ Specified requirements (e.g. security engineering, architecture and design,
development ◻ In draft compliance with legal, regulatory, contractual, ethical and
A14.2.5 Security commercial obligations/expectation, business
◻ Done
engineering process/administrative controls, identification and
A14.2.8 Security authentication, access and privacy controls (including
testing specifications, code, test data and test results), crypto, fraud
A14.3.1 Securing controls, network/messaging security, malware controls, alarms
test data
and alerts, logging, security admin, data integrity, backups,
A14.2.9 resilience and recovery …), and possibly records demonstrating
Acceptance
them in action (e.g. acceptance or authorization to proceed with
testing
implementation), preferably with evidence of a strong business
drive and involvement.

A14.2.2 Change Obviously enough, the documentation includes change control

◻ Specified
control policies, procedures and guidelines, plus less obviously change
◻ In draft authorization and planning, change logs/records, risk
A14.2.3 Post-OS
Requirement Status Interpretation Notes

update app
assessments, prioritization and coordination (e.g. change
reviews
windows, change freezes), back-out plans etc. as evidence of their
A14.2.4
◻ Done correct operation, even under urgent/emergency/exceptional
Restricted
changes to conditions.
packages
Strategies, policies, procedures and guidelines concerning the
(information security aspects of the) use of 3rd-party developers
including contractors, commercial developers and crowd-
sourcing/collaborative arrangements e.g. contracts and
A14.2.7 ◻ Specified agreements, specifications, standards, monitoring, stage-gate
Outsourced ◻ In draft authorizations, acceptance testing, remediation, maintenance
development and support. [This could potentially include the selection and
◻ Done
adoption of commercial, shareware or freeware software
packages, modules, libraries, and cloud services/apps etc.
although that’s not strictly what the standard says.]

A15.1.1 Supplier Documentation in this general area include information security

◻ Specified
security and business continuity strategies, policies and procedures
◻ In draft concerning suppliers and their upstream/peer
A15.1.2 Supplier
agreements ◻ Done suppliers/partners/customers, plus (potentially) customers and
A15.1.3 Supply their suppliers/partners/customers … depending on the
chains organization’s dependence on them and hence the risks. While
A15.2.1 Service the standard is primarily concerned with information- or IT- or
delivery cloud-related products/goods and services, it also mentions
monitoring logistics, financial services etc. Furthermore, there should be
A15.2.2 Changes associated records such as contact points (for routine operations,
to 3rd-party and escalation, commercial and exceptional issues), plus
services
performance and compliance monitoring, incident
management, risk assessment and treatment reports, selection
criteria, contracts/agreements, reviews, assessments or audits
etc. The auditors have limited time and prior knowledge of your
situation, so hopefully digging out some of the obvious/key
policies and contracts will demonstrate willing. Note: supply
networks in most organizations are very complex and hence the
information (and other) risks and dependencies 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
Requirement Status Interpretation Notes
relevant, as well as broader commercial strategies etc.

A16.1.1 Incident
management [Information- or IT- or information security-related] incident
responsibilitie management rôles, responsibilities and objectives, plus policies,
s procedures and guidelines (e.g. routine and emergency contact
A16.1.2 Incident points), plus records/evidence concerning events/incidents
reporting reported, logged, analyzed, possibly escalated, addressed and
A16.1.3 resolved as evidence of compliance. The auditors will welcome
◻ Specified
Vulnerability evidence of a managed, measured, systematic, rational and
reporting ◻ In draft
effective process for handling incidents from cradle-to-grave,
A16.1.4 Incident ◻ Done including post-incident wash-ups and substantive organizational
assessment
changes to embody the learning. For bonus points, show-off your
A16.1.5 Incident
strong forensics capability, and demonstrate that you also
response
discover, respond/react to and learn from near-misses and
A16.1.6 Learning
incidents affecting 3rd-parties.
from incidents
A16.1.7 Forensics
As literally worded, the standard is primarily concerned with
A17.1.1 Planning ensuring the continuity of important information security
infosec activities and controls during a major incident or disaster … but
continuity
you and I know that information security is generally a relatively
A17.1.2 minor consideration under such circumstances and is completely
Implementing
◻ Specified trumped by ensuring the continuity of core business activities,
infosec
continuity hence sensible documentation in this area includes business
◻ In draft
A17.1.3 Verifying continuity strategies, policies, plans, procedures, test/exercise
◻ Done reports etc. demonstrating the effectiveness of the organization’s
infosec
continuity preparations, including but extending far beyond information/IT
A17.2.1 and indeed information risk and security activities. [ISO 22301
Availability of and 22313 are much better guides than ISO27k in this area so you
ICT services may prefer to cite in your SOA and adopt their recommendations]

A18.1.1 These onerous controls require the organization to identify and

◻ Specified
Identifying maintain concerning all external compliance
compliance ◻ In draft requirements/obligations/expectations on the organization
obligations ◻ Done relating to [information, risk, IT, IP and] information security and
A18.1.2 IPR privacy and cryptography, plus IPR (e.g. software licenses,
A18.1.3 Business patents, trademarks and copyright), plus business records
records (e.g. company finances and shareholdings), implying the need for
A18.1.4 Privacy a managed compliance inventory, database etc. with proactive
Requirement Status Interpretation Notes
involvement from legal, regulatory, compliance, procurement, IT
and security professionals plus others … plus the usual raft of
strategies, policies, procedures (e.g. periodic updates to the
requirements, compliance enforcement and compliance
reinforcement/penalties), guidelines and records. Whereas the
standard mostly concerns the organization’s compliance with
external demands or obligations from applicable laws, regulations
and contracts, score bonus points for documentary evidence
A18.1.5 Crypto relating to compliance with internal/corporate requirements,
laws and including 3rd-party compliance with the organization’s contracts,
regulations agreements, licenses etc. (in addition to compliance with
corporate policies, standards etc. in the following controls).
There should be records concerning the organization’s
compliance with specific legal, regulatory and contractual
requirements such as software licenses, records management
policies (retention, destruction etc.), policy for protection of
personal data, and records of where personal data are held (see
also A.8.1).

A18.2.1
Information
These controls concern the organization’s compliance with
security
◻ Specified corporate/internal IT and information risk and security
reviews
A18.2.2 Security ◻ In draft obligations, as demonstrated through policies, procedures and
policy/standar ◻ Done records of reviews, audits, checks, tests, exercises, incidents etc.
ds compliance

◻ Specified Automated network vulnerability scanning, version checks and

A18.2.3 Technical penetration testing may provide regular flows of information,
compliance ◻ In draft
along with reviews and/or audits.
◻ Done