IS

S.NO ISO ANNEX

A.5 INFORMATION SECURITY POLICIES

1 A.5.1.

2 A.5.1.1

3 A.5.1.2

4 A.6 ORGANZATION OF INFORMATION SECURITY

5 A.6.1
 6 A.6.1.1

7 A.6.1.2

8 A.6.1.3

9 A.6.1.4

10 A.6.1.5

11 A.6.2
12 A.6.2.1

13 A.6.2.2

14 A.7 HUMAN RESOURCE SECURITY

15 A.7.1

16 A.7.1.1
17 A.7.1.2

18 A.7.2

19 A.7.2.1

20 A.7.2.2

21 A.7.2.3

22 A.7.3

23 A.7.3.1
24 A.8 ASSET MANAGEMENT

25 A.8.1

26 A.8.1.1

27 A.8.1.2

28 A.8.1.3

29 A.8.1.4

30 A.8.2

31 A.8.2.1
32 A.8.2.2

33 A.8.2.3

34 A.8.3

35 A.8.3.1

36 A.8.3.2

37 A.8.3.3

38 A.9 ACCESS CONTROL

39 A.9.1
40 A.9.1.1

41 A.9.1.2

42 A.9.2

43 A.9.2.1

44 A.9.2.2
45 A.9.2.3

46 A.9.2.4

47 A.9.2.5

48 A.9.2.6

49 A.9.3

50 A.9.3.1

51 A.9.4
52 A.9.4.1

53 A.9.4.2

54 A.9.4.3

55 A.9.4.4
56 A.9.4.5

57 A.10 CRYPTOGRAPHY

58 A.10.1.1

59 A.10.1.2

60 A.11 PHYSICAL AND ENVIRONMENTAL SECURITY

61 A.11.1

62 A.11.1.1

63 A.11.1.2
64 A.11.1.3

65 A.11.1.4

66 A.11.1.5

67 A.11.1.6

68 A.11.2
69 A.11.2.1

70 A.11.2.2

71 A.11.2.3

72 A.11.2.4
73 A.11.2.5

74 A.11.1.6

75 A.11.2.7
76 A.11.2.8

77 A.11.2.9

78 A.12 OPERATIONS SECURITY

79 A.12.1
80 A.12.1.1

81 A.12.1.2

82 A.12.1.3

83 A.12.1.4

84 A.12.2
85 A.12.2.1

86 A.12.3

87 A.12.3.1

88 A.12.4

89 A.12.4.1

90 A.12.4.2

91 A.12.4.3

92 A.12.4.4

93 A.12.5
94 A.12.5.1

95 A.12.6

96 A.12.6.1

97 A.12.6.2

98 A.12.7
 99 A.12.7.1

100 A.13 COMMUNICATIONS SECURITY

101 A.13.1

102 A.13.1.1

103 A.13.1.2

104 A.13.1.3

105 A.13.2

106 A.13.2.1

107 A.13.2.2
108 A.13.2.3

109 A.13.2.4

110 A.14 SYSTEM ACQUISITION, DEVELOPMENT AND MAINTENANCE

111 A.14.1

112 A.14.1.1
113 A.14.1.2

114 A.14.1.3

115 A.14.2

116 A.14.2.1

117 A.14.2.2
118 A.14.2.3

119 A.14.2.4

120 A.14.2.5

121 A.14.2.6
122 A.14.2.7

123 A.14.2.8

124 A.14.2.9

125 A.14.3

126 A.14.3.1

127 A.15 SUPPLIER RELATIONSHIPS

128 A.15.1
129 A.15.1.1

130 A.15.1.2
131 A.15.1.3

132 A.15.2

133 A.15.2.1

A.15.2.2

134

135 A.16 INFORMATION SECURITY INCIDENT MANAGEMENT

136 A.16.1
137 A.16.1.1

138 A.16.1.2

139 A.16.1.3

140 A.16.1.4
141 A.16.1.5

142 A.16.1.6

143 A.16.1.7

144 A.17: Information Security Aspects of Business Continuity Management

145 A.17.1.1

146 A.17.1.2

147 A.17.1.3

148 A.17.2.1

149 A.18: Compliance

150 A.18.1.1

151 A.18.1.2

152 A.18.1.3
153 A.18.1.4

154 A.18.1.5
 ISO 27001:2013
ISO 27001

Management direction of information security

Policies for Information Security

Review of the policies for information security

URITY

Internal organization
Information Security Roles & Responsibilities

Segregation of Duties

Contact with Authorities

Contact with Special Interest Groups

Information Security in Project Management

Mobile devices and teleworking

Mobile device policy

Telworking

Prior to Employment

Screening
Terms & Conditions of Employment

During employment

Management responsibilities

Information Security Awareness, Education & Training

Disciplinary Process

Termination and change of employment

Termination or change of employment responsibilities

Responsibility for assets

Inventory of Assets

Ownership of Assets

Acceptable Use of Assets

Return of Assets

Information classification

Classification of Information
Labelling of Information

Handling of Assets

Media handling

Management of removable media

Disposal of media

Physical media transfer

Business requirements of access control

Access control policy

Access of networks and network services

User access management

User registration and de-registration

User access provisioning

Management of privileged access right

Management of secret authentication information of

users

Review of user access rights

Removal or adjustment of access rights

User responsibilities

User responsibilities

System and application access control

Information access restriction

Secure log-on procedures

Password management system

Use of privileged utility programs

 Access control to program source code

Policy on the use of cryptographic controls

Key management

URITY

Secure areas

Physical security perimeter

Physical entry controls

Securing offices, rooms and facilities

Protecting against external and environmental threats

Working in secure areas

Delivery & Loading Areas

Equipment
Equipment siting and protection

Supporting utilities

Cabling security

Equipment maintenance
Removal of assets

Delivery and loading areas

Secure Disposal or Re-Use of Equipment

Unattended User Equipment

Clear Desk & Screen Policy

Operational procedures and responsibilities

Documented operating procedures

Change management

Capacity management

Separation of Development, Testing & Operational

Environments

Protection from malware

Controls against malware

Backup

Information backup

Logging and monitoring

Event logging

Protection of log information

Administrator and operator logs

Clock synchronization

Control of operational software

Installation of software on operational systems

Technical vulnerability management

Management of systems audit controls

Restrictions on software installation

Information systems audit considerations

Information systems audit controls

Network Security Management

Network controls

Security of network services

Segregation in networks

Information Transfer

Information transfer policies and procedures

Agreements on information transfer

 Electronic messaging

Confidentiality or non-disclosure agreements

NT AND MAINTENANCE

Security requirements of information systems

Information security requirements analysis and

specification
Securing application services on public networks

Protecting application services transactions

Security in development and support processes

Secure development policy

System changes control procedures

Technical review of applications after operating
platform changes

Restrictions on changes to software packages

Secure system engineering principles

Secure development environment

Outsourced development

System security testing

System acceptance testing

Test data

Protection of test data

Information security policy for supplier relationships

Information security policy for supplier relationships

Addressing security within supplier agreements

 Information and communications technology supply
chain

Supplier service delivery management

Monitoring and review of supplier services

Managing Changes to Supplier Services

MANAGEMENT
Management of information security incidents and
improvements
Responsibilities and procedures

Reporting information security events

Reporting information security weaknesses

Assessment of and decision on information security

events
 Response to information security incidents

Learning from information security incidents

Collection of Evidence

ness Continuity Management

Planning Information Security Continuity

Implementing Information Security Continuity

Verify, Review & Evaluate Information Security

Continuity

Availability of Information Processing Facilities

Identification of Applicable Legislation & Contractual
Requirements

Intellectual Property Rights

Protection of Records
 Privacy & Protection of Personally Identifiable
Information

Regulation of Cryptographic Controls

ISO 27001:2013
Description

To provide management direction and support for information security in accordance with business
requirements and relevant laws and regulations.

A set of policies for information security must be defined, approved by management, published and communicated to employe
relevant external parties. The policies must be led by business needs, alongside the applicable regulations and legislation affec
organisation too. These policies in effect are the Annex A controls, also summarised up into a higher level master information
policy document that reinforces the organisation’s key statements around security to share with stakeholders like customers. T
overarching policy becomes much more believable and powerful with independent certification for ISO 27001:2013 from UKAS
Policies also provide the backbone of information security and should be part of the education, training and awareness program
with A7.2.2. The policies set out the principles that members of the organisation and key parties like suppliers must follow. Th
need to be reviewed regularly and updated when necessary in line with A.5.1.2 below.

The policies for information security need to be reviewed at planned intervals, or if significant changes occur, to ensure their co
suitability, adequacy and effectiveness. Whenever changes are made to the business, its risks & issues, technology or legislatio
regulation or if security weaknesses, events or incidents indicate a need for policy change.

Policies must be also reviewed and updated on a regular basis. ISO considers ‘regular’ to be at least annually, which can be har
you are manually managing that many reviews and also dovetailing it with the independent review as part of A.18.2.1.

To establish a management framework to initiate and control the implementation and operation of
information security within the organization.
All information security responsibilities need to be defined and allocated. Information security responsibilities can be general (
protecting information) and/or specific (e.g. the responsibility for granting a particular permission). Consideration should be giv
ownership of information assets or groups of assets when identifying responsibilities. Some examples of the business roles wh
likely to have some information security relevance include; Departmental heads; Business process owners; Facilities manager;
manager; and Internal Auditor. The auditor will be looking to gain assurance that the organisation has made clear who is respo
what in an adequate and proportionate manner according to the size and nature of the organisation. For smaller organisations
generally unrealistic to have full-time roles associated with these roles and responsibilities. As such, clarifying specific informati
responsibilities within existing job roles is important e.g. the Operations Director or CEO might also be the equivalent of the CIS
Chief Information Security Officer, with overarching responsibility for all of the ISMS. The CTO might own all the technology rel
information assets etc.

Conflicting duties and areas of responsibility must be segregated in order to reduce the opportunities for unauthorised or unin
modification or misuse of any of the organisation’s assets. The organisation needs to ask itself whether or not the segregation o
been considered and implemented where appropriate. Smaller organisations may struggle with this, but the principle should b
as far as possible and good governance & controls put in place for the higher risk/higher value information assets, captured as
risk evaluation and treatment.

Appropriate contacts with relevant authorities must be maintained. Remember when adapting this control to think about the l
responsibilities for contacting authorities such as the Police, the Information Commissioner’s Office or other regulatory bodies
GDPR. Consider how that contact is to be made, by whom, under what circumstances, and the nature of the information to be

Appropriate contacts with special interest groups or other specialist security forums and professional associations must also be
maintained. When adapting this control to your specific needs remember that memberships of professional bodies, industry
organisations, forums and discussion groups all count towards this control. It is important to understand the nature of each of
groups and for what purpose they have been set up (e.g. is there a commercial purpose behind it).

Information security needs to be addressed in project management, regardless of the type of project. Information Security sho
ingrained in the fabric of the organisation and project management is a key area for this. We recommend the use of template f
for projects that include a simple repeatable checklist to show that information security is being considered. The auditor will b
see that all people involved in projects are tasked to consider information security at all stages of the project lifecycle so this sh
be covered as part of the education and awareness in line with HR Security for A.7.2.2.

Smart organisations will also dovetail A.6.1.5 with related obligations for personal data and consider security by design along w
Protection Impact Assessments (DPIA) and similar processes to demonstrate compliance with the General Data Protection Reg
(GDPR) and the Data Protection Act 2018.

To ensure the security of teleworking and use of mobile devices

flexible working and a potential security vulnerability. BYOD or Bring Your Own Device is also a major part of the consideration.
there are tremendous benefits to enable staff to use their own devices, without adequate controls on in life use and especially
threats can be considerable too.

An organisation needs to be sure that when mobile devices are used or staff are working off-site its information and that of cus
other interested parties remains protected and ideally within its control. That becomes increasingly difficult with consumer clo
automated backup and personally owned devices shared by family members. An organisation should consider implementing a
Depth” strategy with a combination of complementary physical, technical and policy controls. One of the most important aspe
education, training and awareness around the use of mobile devices in public places too, avoiding the risk of ‘free’ wifi that cou
compromise information quickly or restricting the uninvited observers from looking at the screen on the train journey home.

The auditor will want to see that there are clear policies and controls put into place which provide assurance that information r
secure when working away from organisational physical sites. Policies should cover off the following areas:

registration and management

physical protection
restrictions on what software can be installed, what services and apps can be added & accessed, use of authorised and unauth
developers
operating device updates and patching applications
the information classification accessible and any other asset access constraints (e.g. no infrastructure critical asset access)
cryptography, malware and antivirus expectations
log on, remote disabling, erasure, lockout and ‘find my device’ requirements
backup and storage
family and other user access conditions (if BYOD) e.g. separation of accounts
use in public places
connectivity and trusted networks

A policy and supporting security measures must also be implemented to protect information accessed, processed or stored at
sites. Teleworking refers to home-working and other off-site working such as on supplier or customer sites. For teleworking sta
education, training and awareness relating to potential risks is critical. The auditor will expect to see decisions relating to mobil
and teleworking use and security measures based on appropriate risk assessment, balancing the need for flexible working agai
potential threats and vulnerabilities such use would introduce.

Teleworking is also closely related to many of the other Annex A controls areas in A.6, A.8, A.9, A .10, A.11, A.12 and A.13 so jo
as part of the office and teleworking approach to avoid duplication and gaps. A.7 is also essential to get right for screening and
recruitment of teleworkers and management over the lifecycle becomes key to include in audits and demonstrate to auditors t
teleworkers are not a poorly managed threat.

To ensure that employees and contractors understand their responsibilities and are suit- able for the roles for which they are co

A good control covers background verification and competence checks on all candidates for employment. These must be carrie
accordance with the relevant laws, regulations and ethics, and should be proportional to the business requirements, the classifi
the information that will be accessed and the perceived risks associated. For example, staff accessing higher level information a
carry more risk may be subject to much more stringent checks than staff who only ever get access to public information or han
with limited threat. Putting in place adequate and proportionate HR controls at all stages of employment helps to reduce the li
accidental or malicious threats. The screening should also take place for contractors (unless their parent organisation meets yo
security controls e.g. has their own ISO 27001 and does their own background checks.) An auditor will expect to see a screenin
with clear procedures being operated consistently each time to also help avoid any preference/prejudice risks too. Ideally this w
aligned with the overall organisation hiring process.
The contractual agreement with employees and contractors must state their and the organisation’s responsibilities for informa
security. These agreements are a good place to put key information security general and individual responsibilities as they carr
weight – meaning they are backed up by the law. This is also very important as regards GDPR and the new Data Protection Act
should reference and cover a whole range of control areas including overall compliance with the ISMS as well as more specifica
acceptable use, IPR ownership, return of assets etc. We recommend working with an HR Lawyer if you are unsure as the conse
getting employment contracts wrong from an information security perspective (and other dimensions) can be significant.

To ensure that employees and contractors are aware of and fulfil their information security responsibilities.

A good control describes how employees and contractors apply information security in accordance with the policies and proce
the organisation. The responsibilities placed upon managers should include requirements to; Ensure that those they are respon
understand the information security threats, vulnerabilities and controls relevant to their job roles and receive regular training
A7.2.2); Ensure buy-in to proactive and adequate support for relevant information security policies and controls; and Reinforce
requirements of the terms and conditions of employment. Managers play a critical role in ensuring security consciousness and
conscientiousness throughout the organisation and in developing an appropriate “security culture”.

All employees and relevant contractors must receive appropriate awareness education and training to do their job well and sec
must receive regular updates in organisational policies and procedures when they are changed too, along with a good understa
the applicable legislation that affects them in the role. It is common for the information security team to partner with HR or a
Development team to carry out skills, knowledge, competence and awareness assessments and to plan and implement a progr
awareness, education and training throughout the employment lifecycle (not just at induction). You need to be able to demons
training and compliance to auditors. Also carefully consider how the training and awareness is delivered to give the staff and c
resource the best chance of understanding and following it – this means careful attention to content and medium for delivery.
There needs to be a documented disciplinary process in place and communicated (in line with A7.2.2 above). Whilst focused h
disciplinary action following security breaches, it can also be dovetailed with other disciplinary reasons. If your organisation al
recognised HR disciplinary process then ensure it covers information security in the manner required for the ISO 27001:2013 st

To protect the organization’s interests as part of the process of changing or terminating employment

Information security responsibilities and obligation that remain valid after termination or change of employment must be defin
communicated to the employee or contractor and enforced. Examples include keeping information confidential and not leavin
information that belongs to the organisation. It is really important to ensure that information remains protected after an emplo
contractor leaves the organisation, as people themselves are walking data stores.

The contractual terms & conditions should reinforce this, and the leaver’s process and/or contract termination process (includi
assets) should include a reminder to individuals that they have some responsibilities to the organisation even after they have le
auditor will want to see evidence of leavers having returned their assets and the process being closed off and documented to
demonstrate assets are updated in the asset inventory (A8.1.1) where appropriate too.

This is not just about termination and exit. If an employee changes role e.g. moving from operations to sales, you should do a r
demonstrate they no longer have access to information assets that are not required in the new role, and are provisioned with a
information assets needed for the future.
To identify organizational assets and define appropriate protection responsibilities

Any assets associated with information and information processing facilities need to be identified and managed over the lifecy
up to date. A register or inventory of those assets has to be put together that shows how they are managed and controlled, ba
their importance (which also dovetails neatly into information classification below). This lifecycle of the information generally i
creation, processing, storage, transmission, deletion and destruction stages.

All information assets must have owners. Asset management ownership can be different to legal ownership too, and it can be d
individual level, department, or other entity. Ownership should be assigned when the assets are created. The asset owner is re
for the effective management of the asset over the whole of the asset’s lifecycle. They can delegate management of that too a
ownership can change during that lifecycle as long as both are documented.

Acceptable use of information and of assets is important to get right. Rules for acceptable use of assets is often documented in
“Acceptable Use Policy”. The rules for acceptable use must take into consideration employees, temporary staff, contractors and
parties where applicable across the information assets they have access to. It is important that all relevant parties have access
of documented acceptable use rules and these are reinforced during regular training and information security awareness, com
related activity.

All employees and external party users are expected to return any organisational and information assets upon termination of t
employment, contract or agreement. As such it must be an obligation for employees and external users to return all the assets
obligations would be expected in the relevant agreements with staff, contractors and others. A solid, documented process is als
to ensure that the return of assets is appropriately managed and can be evidenced for each person or supplier that goes throu
aligns with the exit controls in Annex 7 for Human Resource Security and Annex 13.2.4 for confidentiality agreements, and Ann
supplier activity. Where assets are not returned according to the process, unless otherwise agreed and documented as part of
process, the non-return should be logged as a security incident and followed-up in line with Annex A.16. The return of assets p
never fool proof and this also underlines the need for periodic audit of assets to ensure their continued protection
To ensure that information receives an appropriate level of protection in accordance with its importance to the
organization

Information must be classified in terms of legal requirements, value, criticality and sensitivity to any unauthorised disclosure or
modification, ideally classified to reflect business activity rather than inhibit or complicate it. For example, information made p
available e.g. on a website might just be marked ‘public’ whereas confidential or commercial in confidence are obvious for the
being more sensitive than public.

Information classification is one of the key controls used to ensure that assets are adequately and proportionately protected. M
organisations have 3-4 classification options to allow effective management of the information taking into account its value and
importance. It can however be as simple or as complex as required to ensure the correct level of granularity for the protection
Remember if you keep it really simple and have too few classifications that might mean you are over or under engineering con
many classification options is likely to confuse end users on what one to adopt and create additional overhead on the managem
scheme. As with all controls this one needs to be reviewed regularly to ensure its ongoing fitness for purpose.
An appropriate set of procedures for information labelling must be developed and implemented in accordance with the inform
classification scheme adopted by the organisation. Procedures for information labelling will need to cover information and rela
in both physical and electronic formats. This labelling should reflect the classification scheme established in 8.2.1. The labels sh
easily recognisable and easy to manage in practice otherwise they will not get followed. For example it could be easier to defa
that everything is confidential in the digital systems unless expressly labeled otherwise, rather than get staff to label every CRM
with a commercial in confidence statement! Be clear on where this defacto labelling is being done and document it in your po
remember to include it in the training for staff.

Procedures for handling assets need to be developed and implemented in accordance with the information classification schem
following should be considered; Access restrictions for each level of classification; Maintenance of a formal record of the autho
recipients of assets; Storage of IT assets in accordance with manufacturers’ specifications, marking of media for authorised par

If the organisation handles information assets for customers, suppliers and others, it is important to either demonstrate a map
e.g. customer classification of official sensitive maps to our organisation of commercial in confidence, or that the additional cla
would be dealt with in other ways to show it is being protected.

To prevent unauthorized disclosure, modification, removal or destruction of information stored on media.

Procedures must be put in place for the management of removable media in accordance with the classification scheme. Gener
removable media must be risk assessed and it may be necessary to carry out use-specific risk assessments beyond that too. Re
media should only be allowed if there is a justified business reason. If no longer required, the contents of any re-usable media
made unrecoverable and securely destroyed or erased. All media should be stored in a safe, secure environment, in accordance
manufacturers’ specifications and additional techniques like cryptography considered where appropriate (i.e. as part of the risk
assessment). Where necessary and practical, authorisation should be required for media removed from the organisation, and a
kept in order to maintain an audit trail.

When no longer required media must be disposed of securely by following documented procedures. These procedures minimi
of confidential information leakage to unauthorised parties. The procedures should be proportional to the sensitivity of the inf
being disposed. Things that should be considered include; whether or not the media contains confidential information; and ha
procedures in place which help identify the items which might require secure disposal.

Any media containing information needs to be protected against unauthorised access, misuse or corruption during transportati
already publicly available). The following should be considered to protect media when being transported; Reliable transport or
should be used – perhaps a list of authorised couriers should be agreed with management; Packaging should be sufficient in or
protect the contents from any physical damage during transit; and Logs should be kept, identifying the content of the media an
protection applied. It should also be noted that when confidential information on media is not encrypted, additional physical p
the media should be considered

To limit access to information and information processing facilities.

An access control policy must be established, documented and reviewed regularly taking into account the requirements of the
for the assets in scope. Access control rules, rights and restrictions along with the depth of the controls used should reflect the
information security risks around the information and the organisation’s appetite for managing them. Put simply access contro
who needs to know, who needs to use and how much they get access to.

Access controls can be digital and physical in nature, e.g. permission restrictions on user accounts as well as limitations on who
certain physical locations (aligned with Annex A.11 Physical and Environment Security). The policy should take into account:
Security requirements of business applications and align with the information classification scheme in use as per A.8 Asset Ma
Clarify who needs to access, know, who needs to use the information – supported by documented procedures and responsibili
Management of the access rights and privileged access rights (more power – see below) including adding, in life changes (e.g.
users/administrators controls) and periodic reviews (e.g. by regular internal audits in line with requirement 9.2.
Access control rules should be supported by formal procedures and defined responsibilities;
Access control needs to be reviewed based on change in roles and in particular during exit, to align with Annex A.7 Human Res
Security.

The principle of least access is the general approach favoured for protection, rather than unlimited access and superuser rights
careful consideration. As such users should only get access to the network and network services they need to use or know abo
job. The policy therefore needs to address; The networks and network services in scope for access; Authorisation procedures f
who (role based) is allowed to access to what and when; and Management controls and procedures to prevent access and mon
life. This also needs to be considered during onboarding and offboarding, and is closely related to the access control policy itse

To ensure authorized user access and to prevent unauthorized access to systems and services.

A formal user registration and de-registration process needs to be implemented. A good process for user ID management inclu
able to associate individual IDs to real people, and limit shared access IDs, which should be approved and recorded where don
onboarding and exit process ties in with A7 Human Resource Security to show quick and clear registration/deregistration along
avoidance of reissuing old IDs. A regular review of ID’s will illustrate good control and reinforces ongoing management. That ca
with the internal audits noted above for access control audits, and periodic reviews by the information asset or processing app
owners.

A process (however simple and documented) must be implemented to assign or revoke access rights for all user types to all sys
services. Done well it ties in with the points above as well as the broader HR Security work. Provisioning and revoking process s
include; Authorisation from the owner of the information system or service for the use of the information system or service; Ve
the access granted is relevant to the role being done; and protecting against provisioning being done before authorisation is co
User access should always be business led and access based around the requirements of the business. This might sound burea
it doesn’t need to be and effective simple procedures with role based access by systems and services can address it.
This is about managing usually more powerful and higher ‘privileged’ levels of access e.g. systems administration permissions v
normal user rights. The allocation and use of privileged access rights has to be tightly controlled given the extra rights usually c
over information assets and the systems controlling them. For example the ability to delete work or fundamentally affect the in
the information. It should align with the formal authorisation processes alongside the access control policy. That could include
system clarity on privileged access rights (which can be managed inside the application); allocation on a need-to-use basis not
approach; A process and record of all privileges allocated should be maintained (alongside the information asset inventory or a
the A.9 evidence; and the competence of users granted the rights must be reviewed regularly to align with their duties. This is
good area to include in the internal audit to demonstrate control.

One of the biggest contributory factors to failures or breaches of systems is inappropriate and blanket use of system administra
privileges with human error leading to more damage or loss than if a ‘least access’ approach were taken. Other good practice
this area includes the separation of the systems administrator role from the day to day user role and having a user with two ac
they perform different jobs on the same platform.

Secret authentication information is a gateway to access valuable assets. It typically includes passwords, encryption keys etc. s
be controlled through a formal management process and needs to be kept confidential to the user. This is usually tied into em
contracts and disciplinary processes (A.7) and supplier obligations (A13.2.4 and A.15) if sharing with external parties. Procedur
be established to verify the identity of a user prior to providing new, replacement or temporary secret authentication informati
default secret authentication information provided as part of a new system use should be changed as soon as possible.

Asset owners must review users’ access rights at regular intervals, both around individual change (onboarding, change of role a
well broader audits of the systems access. Authorisations for privileged access rights should be reviewed at more frequent inte
their higher risk nature. This ties in with 9.2 for internal audits and should be done at least annually or when major changes tak

As outlined above access rights of all employees and external party users to information and information processing facilities n
removed upon termination of their employment, contract or agreement, (or adjusted upon change of role if required). A good
and procedures dovetailed in with A.7 will also ensure this is achieved and demonstrated for audit purposes when people leav

To prevent unauthorized access to systems and applications

This is simply about making sure that users follow the policies and will therefore tie in with A7 Human Resource Security for co
user education for awareness and compliance, as well as common sense practices. These include: Keep any secret authenticati
information confidential; Avoid keeping a record of it that can be accessed by unauthorised parties; Change it whenever there
suggestion of possible compromise; select quality passwords with sufficient minimum length and strength to follow broader pa
policy controls in Annex A.9.4.

To prevent unauthorized access to systems and applications.

Access to information and application system functions must be tied into the access control policy. Key considerations should in

Role based access control (RBAC);

Levels of access;
Design of “menu” systems within applications;
Read, write, delete and execute permissions;
Limiting output of information; and
Physical and/or logical access controls to sensitive applications, data and systems.
The auditor will check to see that considerations have been made for limiting access within systems and applications that supp
control policies, business requirements, risk levels and segregation of duties.

Access to systems and applications must be controlled by a secure log-on procedure to prove the identity of the user. This can
the typical password approach into multi factor authentication, biometrics, smart cards, and other means of encryption based
being considered. Secure log on should be designed so it cannot be easily circumvented and that any authentication informatio
transmitted and stored encrypted to prevent interception and misuse. ISO 27002 guidance is significant around this topic, as ar
bodies like the National Cyber Security Centre (NCSC). Additional tips include:

Log-on procedures should be designed so that they cannot be easily circumvented and that any authentication information is t
and stored encrypted to prevent interception and misuse.
Log-on procedures should also include a display stating that access is for authorised users only. This is designed to support cyb
legislation such as the Computer Misuse Act 1990 (UK).
Both successful and unsuccessful log-ons and log-offs should be logged in a secure manner to provide forensic evidential abilit
for unsuccessful attempts and possible lock-outs should be considered.
Depending on the nature of the system access should be restricted to certain times of day or periods of time and potentially ev
restricted according to location.
In practice the business needs and information at risk should drive the log on and log off procedures. It is not worth having 25
on, then have rapid time outs etc if staff are then unable to do their job well and spend a disproportionate amount of time in t

The purpose of a password management system is to ensure quality passwords meet the required level and are cons
applied. Password generation and management systems provide a good way of centralising the provisioning of acces
with any control need to be carefully implemented to ensure adequate and proportionate levels of protection. Wher
possible users should be able to choose their own passwords as this makes them easier to remember than machine-
ones, however, it needs to be up to a certain level of strength. There are lots of conflicting views on password manag
systems and password policies so we encourage organisations to look at the frequently changing best practices and a
approaches based on the risk appetite and culture of the organisation. As mentioned above NCSC is a good place to
latest practices or simply ask us to introduce you to one of our partners for help.

Utility computer programmes that might be capable of overriding system and application controls need to be carefully manage
system and network utility programs can create an attractive target for malicious attackers and access to them must be restrict
smallest number of people. As such utility programmes can be easily located and downloaded from the internet it is also impo
users are restricted in their ability to install software as much as possible weighed against business requirements and risk asses
of utility programmes should be logged and monitored/reviewed periodically to satisfy auditor requests.
Access to program source code must be restricted. Access to program source code and associated items (such as designs, spec
verification plans and validation plans) should be strictly controlled. Programme source code can be vulnerable to attack if not
protected and can provide an attacker with a good means to compromise systems in an often covert manner. If the source cod
to the business success it’s loss can also destroy the business value quickly too.

To prevent unauthorized physical access, damage and interference to the organization’s information and
information processing facilities.

This describes the security perimeters and boundaries which have areas that contain either sensitive or critical information and
information processing facilities such as computers, laptops etc. A physical security perimeter is defined as “any transition bou
between two areas of differing security protection requirements”. This might be quite specific such as; At the outermost bound
site and encompassing outdoor and indoor spaces; Between outside a building and inside it; Between a corridor and office or b
the outside of a storage cabinet and inside it. It could also be stated simply as being the HQ with its address and the boundarie
around it.

Examples of the types of property and premises the organisation will need to consider in terms of physical security could includ

The Data centres that host information assets;

Head office;
Workers who tend to work from home; and
Workers who travel and therefore use hotels, customer premises etc.
With increasing outsourcing e.g. for datacentres and use of rented offices it is also important to reference these controls with t
policy in A15.1 and the numerous other policies that affect home/mobile/teleworkers too. This also dovetails and relates to yo
4.3.

Put in simple terms, the organisation must establish secure areas that protect the valuable information and information assets
authorised people can access. This is also related to the risk assessment and risk appetite for an organisation in line with 6.1 ac
address risks need
Secure areas and opportunities.
to be protectedAsby
a basic example, offices
the appropriate containing
entry controls to valuable information
ensure only should
authorised only be
personnel areaccessed
allowedby emploA
access.
organisation,
basic example,oronly
by permission being granted
those employees who haveforbeen
others e.g. the
given visitors,
alarmand external
access codecleaners/facilities
and received a keymaintenance resources
can access the office. wh
Mo
been approved
averse in lineand
organisations with
orthe supplier
those policy.sensitive information at threat might go much deeper with policies that include b
with more
and scanning solutions too.

Entry controls will need to be selected and implemented based on the nature and location of the area being protected, and the
implement such controls if for example, the location is not owned by the organisation. The processes for granting access throu
entry controls need to be robust, tested and monitored and may also need to be logged and audited. The control of visitors wil
especially important and the processes related to such should be considered. Extra consideration should be given to access bei
to areas in which sensitive or classified information is being processed or stored. Whilst areas containing key IT infrastructure e
in particular need to be protected to a greater extent and access limited to only those that really need to be there. The auditor
to see that appropriate controls are in place as well as regularly tested and monitored.
Security of offices, rooms and facilities may seem easy and obvious, but it is worth considering and regularly reviewing who sh
access, when and how. Some of the things that often get missed are; Who can see or even hear into the office from outside an
do about it?; Is access updated when staff leave or transfer so no longer need access to this particular room; Do visitors need t
escorted in this area and is so, are they?; And are staff vigilant about challenging and reporting people they do not recognise?
that are shared with others (eg if a rented office meeting room) policies would also include the protection and or removal of va
assets when it is not occupied by the organisation – ranging from laptops, through to information posted on whiteboards, flipc

The external auditor will be inspecting the security controls for offices, rooms and facilities and checking to see that there is ev
adequate, risk-based control implementation, operation and review on a periodic basis.

This control describes how physical protection against natural disasters, malicious attacks or accidents is prevented.

Environmental threats can be naturally-occurring (e.g. floods, tornados, lightning etc) or man made (e.g. water leakage from fa
unrest etc). Considerations for such threats needs to be made and risks identified, assessed and treated appropriately. Some th
sitting on a flood plain) may be unavoidable without considerable cost or inconvenience, however, that does not mean that the
actions that can be taken. Specialist advice may be required for some aspects of environmental management and should be co
necessary. Understanding your location and what is in the immediate vicinity is critical to identifying potential risks. The audito
looking for evidence that thought has gone into identifying potential threats and vulnerabilities (both naturally-occurring and m
and that environmental risks have been assessed and either treated or tolerated accordingly.

One the access controls have been identified and implemented for secure areas, it is important that these are complemented w
procedural controls relating to risks that might happen when inside the secure area. For example there might need to be:

A restricted awareness of the location and function of secure areas;

Restrictions on the use of recording equipment within secure areas;
Restriction on unsupervised working within secure areas wherever possible;
In and out monitoring and logging.
Having inspected the secure area access controls, the auditor will then be looking to see that these are supported, where nece
appropriate
Access pointspolicies
such asand procedures
delivery and that
and loading evidence
areas of their
and other management
points is maintained
where unauthorised persons could enter the premises shall b
controlled and, if possible, isolated from information processing facilities to avoid unauthorised access. Cloud only or digital wo
might not have any need for a policy or control around delivery and loading areas; in that instance they would note it and spec
exclude this from the Statement of Applicability (SOA).

For some organisations, delivery/loading areas are either not available or not controlled by the organisation (e.g. a shared offic
accommodation). However, where the organisation can control or influence these areas, it is important that risks are identified
assessed and appropriate controls are therefore implemented. Examples of these controls may include; Location away from th
office building; Extra guarding; CCTV monitoring & recording; And procedures to prevent external and internal access being op
same time. The auditor will inspect the delivery and loading protection to assure there are appropriate controls relating to the
incoming materials (e.g. deliveries) and the control of outgoing materials (e.g. for information leakage prevention). Although, t
assurance around delivery and loading relative to the assessed risk levels that the auditor will be looking for will depend on the
and ownership of such facilities.

To prevent loss, damage, theft or compromise of assets and interruption to the organization’s operations.
Equipment needs to be protected from power failures and other disruptions caused by failures in supporting utilities. For exam
related to failing or faulty power supplies should be assessed and considered. This might include; Dual power supplies from diff
stations; Backup power generation facilities; Regular testing of power provision and management. For telecommunications, in
maintain the ability for them to continue – considerations might include; Dual or multiple routing; Load balancing and redunda
switching equipment; Bandwidth capacity monitoring and alerting. Many of the risks will relate to the “availability” of informati
processing systems and so controls should support the business requirements for availability in line with any business continuit
and impact assessments carried out for this purpose. The auditor will be looking for evidence that controls have been regularly
ensure they function correctly to the desired levels (backup-generators etc).

Power and telecommunications cabling carrying data or supporting information services needs to be protected from intercepti
interference or damage. If power and network cables are not sited and protected adequately it is possible that an attacker may
intercept or disrupt communications or shut down power provision. Wherever possible, network and power cables should be
underground or otherwise protected and separated in order to protect against interference. Depending on the sensitivity or cla
of data it may be necessary to separate communications cables for different levels and additionally inspect termination points
unauthorised devices. The auditor will be visually inspecting the cables and if they are relevant to the level of classification/risk
evidence of visual inspection.

Equipment should be correctly maintained to ensure its continued availability and integrity. The requirement for routine, preve
reactive maintenance of equipment will vary according to the type, nature, siting environment and purpose of the equipment
contractual agreements with manufacturers and third party suppliers. Maintenance needs be carried out on equipment at app
frequencies to ensure that it remains effectively functional and to reduce the risk of failure. It is a good idea to keep maintenan
schedules as evidence for the auditor if your equipment needs servicing or has repairs (This can be neatly tied into the A8.1.1 i
asset inventory if desired). Logs of this maintenance should include who carried out the maintenance, what was done and who
the maintenance. The auditor will be checking these logs to see that the schedules are adequate and proportionate, and that t
activities have been appropriately authorised and conducted.

Equipment, information or software taken off-site needs management too. That might be controlled with some form of check i
process or more simply associated to an employee as part of their role and managed in accordance with their terms and condi
employment – Annex A 7 which should deal with information security of course!)
In the ever mobile working world, some assets such as mobile devices, may be routinely removed from organisational premise
facilitate mobile or home working. Where assets are not designed to be routinely removed from site or if they are of a sensitive
classified, valuable or fragile nature then processes should be in place to request and authorise removal and to check return of
Consideration for limiting the length of time assets are allowed to be removed for should be made and should be risk based. Th
will be looking to see that these risk assessments have been carried out for when non-routine removal of assets occurs and for
that determine what is and isn’t routine.
Security controls need to be applied to off-site assets, taking into account the different risks involved with working outside the
organisation’s premises. This is a common area of vulnerability and it is therefore important that the appropriate level of contr
implemented and tie into other mobile controls and policies for homeworkers etc. Considerations should be made and risk ass
carried out for assets that are taken off site, either routinely or by exception. Controls will likely include a mixture of; Technical
such as access control policies, password management, encryption; Physical controls such as Kensington Locks might also be co
too; alongside policy and process controls such as instruction to never leave assets unattended in public view (e.g. locking in th
the car). It is particularly important to review security incident trends relating to off-site assets. The auditor will expect to see e
this risk assessment taking place and the proportionate controls selected according to the evaluated risk levels. They will also e
see evidence of policy compliance.

All items of equipment including storage media should be verified to ensure that any sensitive data and licensed software has b
removed or securely overwritten prior to disposal or re-use. This is another area of common vulnerability where many incident
arisen from poor disposal or re-use practices. If equipment is being disposed of that contained sensitive information, it is critica
bearing devices and components are either physically destroyed or securely wiped using appropriate tools and technologies. If
is going to be re-used it is important that any previous data and potentially installed software is securely “wiped” and the devic
to a known “clean” state. Depending on the level of sensitivity of data contained on equipment being destroyed it may be nece
ensure physical destruction and this should be done using a process that can be fully audited. Often third party companies are
disposal and if this is the case it is essential to ensure the appropriate level of “certificate of destruction” is provided – powerfu
may expect to see this too if you have been holding valuable customer data and part of your contract with them specifies secu
destruction. For this control, the auditor will be looking to see that appropriate technologies, policies and processes are in plac
evidence of destruction or secure erasure have been carried out correctly when required (tied back to decommissioning in you
information asset inventory where relevant too).

As with securing offices, users must ensure that any unattended equipment has the appropriate protection, even if that is a pa
lock screen for basic information security. It is common sense to protect equipment when leaving it unattended, however this
on the levels of trust placed in the location where the device is being left (e.g. hotel bedrooms, conference venues etc). Organi
premises need to be considered too if there is a risk, e.g. high volume of visitor traffic, hot desking by frequently changing staff
differing roles. If equipment is being left overnight where cleaning and other contractors may have access out of normal office
important to consider the risks of theft and tampering and apply sensible and adequate controls. Policies, process and awarene
programmes should be in place to ensure that users are aware of their responsibilities when leaving equipment unattended eit
the organisation or outside if mobile. The auditor will be looking to see that layers of control are in place that are appropriate t
levels and that there is evidence of compliance checking (e.g. walk-around inspections after hours or during lunchbreaks is a po
for onsite audits).
Operating procedures for papers and removable storage media and a clear screen policy for information processing facilities sh
generally be adopted unless all the other controls and risks mean they are not required. Clear desk and clear screen policies ar
considered good practice and are relatively simple to implement, however, in some time-sensitive operational environments th
be practical. In this case other controls designed to manage the risks can be implemented instead. For example, if an office has
level of physical access control with very little visitor and external contractor traffic then such controls may be deemed unnece
however, the risk of “insider threat” may still be relevant and may be at unacceptable levels. Ultimately as with all security con
the decisions relating to the implementation or not of clear desk and clear screen policies should be based on risk assessment.
auditor will be looking to see how the decisions to implement or not clear desk and clear screen policies were made and review
appropriate frequency. If such policies are in place, they will be looking for evidence of compliance testing and the reporting an
management of any breaches.

Operating procedures for papers and removable storage media and a clear screen policy for information processing facilities sh
generally be adopted unless all the other controls and risks mean they are not required. Clear desk and clear screen policies ar
considered good practice and are relatively simple to implement, however, in some time-sensitive operational environments th
be practical. In this case other controls designed to manage the risks can be implemented instead. For example, if an office has
level of physical access control with very little visitor and external contractor traffic then such controls may be deemed unnece
however, the risk of “insider threat” may still be relevant and may be at unacceptable levels. Ultimately as with all security con
the decisions relating to the implementation or not of clear desk and clear screen policies should be based on risk assessment.
auditor will be looking to see how the decisions to implement or not clear desk and clear screen policies were made and review
appropriate frequency. If such policies are in place, they will be looking for evidence of compliance testing and the reporting an
management of any breaches.

To ensure correct and secure operations of information processing facilities.

Operating procedures must be documented and then made available to all users who need them. Documented operating proc
to ensure consistent and effective operation of systems for new staff or changing resources, and can often be critical for disaste
business continuity and for when staff availability is compromised. Where information systems are “cloud-based” traditional op
activities such as system start-up, shut-down, backup etc become less relevant and may often be outsourced to a cloud provide
traditional computing environments and architectures operating procedures are much more likely to be required. It is importan
documents are maintained in a correct and current state and should therefore be subject to formal change management and p
review procedures – this is key, as the auditor will be specifically looking to see this.

We often get asked about how much detail is needed, and what areas of the business need to have documented procedures. T
common sense approach. For example, if you have real staff stability, the implicit procedures are very well understood and res
place across that resource pool, simple bullet points may be enough to form a checklist style documented procedure. Similarly
procedures are evolving or regularly changing e.g. because of fast growth you want to have procedures that can be easily and q
updated too. Again if lots of new resource is being added and the area has risk and complexity around it, then more depth to t
procedures may be needed so it is unambiguous about what, when, how, who etc.

The areas of the business that need to be considered for documented procedures should be where your information assets are
through incorrect operation, which of course will be identified as part of the risk assessment in line with 6.1. That might includ
development, IT management, through to financial accounting, customer management, consulting or manufacturing work etc
on the nature of the business.

The organisation, business procedures, information processing facilities and systems that affect information security need to be
controlled. Properly controlled change management is essential in most environments to ensure that changes are appropriate,
properly authorised and carried out in such a manner as to minimise the opportunity for either malicious or accidental compro
Change management applies across the organisation, its processes, information processing facilities, networks, systems, and ap
Audit logs are required to provide evidence of the correct use of change procedures. The auditor will want to point out that ch
procedures do not have to be overly complicated, but need to be appropriate to the nature of change being considered. You m
capture evidence of amendments and version control changes as you go, or operate much deeper more complex change mana
and include retraining and communications as well as have more significant investment and sign off processes.

The use of resources must be monitored, tuned and projections made of future capacity requirements to ensure the required s
performance to meet the business objectives. Capacity management typically looks at three primary types; Data storage capac
database systems, file storage areas etc.); Processing power capacity – (e.g. adequate computational power to ensure timely p
operations.); and Communications capacity – (often referred to as “bandwidth” to ensure communications are made in a timel
Capacity management also needs to be; Pro-active – for example, using capacity considerations as part of change managemen
– e.g. triggers and alerts for when capacity usage is reaching a critical point so that timely increases, temporary or permanent c
made.

Good policies for development, testing and operational environments would confirm they must be separated to reduce the risk
unauthorised access or changes to the operational environment. Keeping development, testing and live operational IT environm
separate is good practice as this helps with segregation of duties and unauthorised access to the live environment & data. Chan
new developments should be thoroughly tested in a separate area before being deployed to the live operating environment. Id
development personnel should not have access to the live environment but this may not be possible, especially in small organi
Once separated, it is important to check that testers are not accidentally (or deliberately) using test environments as live. The a
be checking to see that development, test and live environments are separated and that there are formal procedures including
appropriate levels of authorisation for moving changes and developments from one environment to another.

To ensure that information and information processing facilities are protected against malware.
Detection, prevention and recovery controls to protect against malware must be implemented, combined with the appropriate
awareness. This is a section about which most organisations have some level of awareness, understanding and implementation
malware protection can take a number of different forms aside from the obvious “anti-virus software”. Other controls such as r
around the use of removable media or restrictions on the installation of software by users – helping to prevent the use of unau
software – are also valuable. Patching of known system and software vulnerabilities in a timely manner is also critical. Often vir
designed to look for unpatched systems and software in which known vulnerabilities may reside. It is important that any malwa
protection is kept up to date, both in terms of relevant “signature files” and the software itself.

Information backup

To protect the valuable information against loss, a good control describes how backup copies of information, software and syst
shall be taken and tested regularly in accordance with an agreed backup policy.

Backup regimes need to be designed according to business requirements and risk levels relating to unavailability of information
important to ensure that such regimes do support actual needs rather than simply being “we do backups”. When backups are t
information should be protected at the same level as the live data by minimum and should be stored away from the live enviro
minimise the risk of a single compromise taking down both the live environment and the backups. Regular testing of backups i
ensure that restorations will be successful and achieved in a timely manner. Monitoring and recording of backups should be im
to ensure that they are occurring in line with the backup policy. Smart auditors will want to see reports against failed backups
done to ensure they are working as expected. Backup policies need to be considered around what, where from and where to,
– taking into account office and homeworkers, mobile etc where there are considerations about mobile and removal storage ba
have increased risks in the event of loss that might be addressed through encryption or other controls.

To record events and generate evidence

Event logs recording user activities, exceptions, faults and information security events need to be produced, kept and reviewed
Logging and monitoring mechanisms form an important part of a “defence-in-depth” strategy for security management by pro
Logging
detectivefacilities and log information
and investigation must
capabilities. be logs
Event protected againste.g.
of all types, tampering and unauthorised
system logs, access controlaccess. It ismay
logs, etc., alsobecritical to ensure
required, espe
stored
regardingin aincident
secure and tamper-proof
management and manner
auditing.soLogs
thatwill
anyoften
evidence
needderived
to storefrom them can
potentially beamounts
huge evidenced of in a provableso
information manner.
it is impT
especially important in any
capacity considerations are form
made.of legal proceedings relating to evidence from the log. Because logs potentially contain large a
sensitive data, it is important that they are protected and secured adequately. It is also important to consider that if the logs co
personally identifiable information, which they almost certainly will, such as user ID and the actions performed by that UID, the
to fall under the requirements of data protection and privacy legislation including data retention.
A good control describes how any system administrator and system operator activities need to be logged and the logs protecte
regularly reviewed. Special consideration should be given to greater levels of logging for privileged accounts such as system ad
and operators.

The clocks of all relevant information processing systems within an organisation or security domain must be synchronised to a
reference time source. System clock synchronisation is important, especially when evidencing events as part of an investigation
proceeding as it is often impossible or very difficult to prove “cause & effect” if clocks are not synchronised correctly. The audit
paying special attention to ensure that this has been done.

To ensure the integrity of operational systems.

Procedures must be implemented to control the installation of software on operational systems. As with any security related co
important that the installation of software on operational systems is formally controlled. Whilst this may not always be possible
in small organisations, the principle remains true. Issues related to the inappropriate installation or change of software on oper
systems can include; Malware infected software being installed; Capacity issues; or Software that can enable malicious insider
being installed (e.g. hacking tools). Beyond restricting and limiting the installation of software on operational systems, it is also
to formally control the legitimate installation. It is good practice to ensure wherever possible that, for example; Formal change
management has taken place, including appropriate levels of authorisation; Roll-back procedures are in place; and Previous ve
software and change histories are kept securely. Each change should consider both the business requirements and the security
requirements and risks in line with formal change management procedures. The auditor will expect to see records of software
and installations that have been kept, which they will want to inspect/sample.

To prevent exploitation of technical vulnerabilities.

Information about technical vulnerabilities of information systems being used must be obtained in a timely fashion, the organis
exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk. Any vulnerability is a
in security protection and must be dealt with effectively and efficiently where risk levels are unacceptable. Technical vulnerabil
been at the heart of many large security breaches reported in the media (and those that aren’t!) and so it is essential that form
managed process are in place at an adequate and proportionate level. There needs to be a balance between the security impe
implementing vulnerability patches as quickly as possible and the security imperative of testing patches sufficiently to ensure c
availability and integrity of systems and the minimisation of incompatibilities. Awareness can also play an important part and it
therefore sensible to have a communications strategy relating to updating users when vulnerabilities exist that can be managed
degree through user behaviours. The auditor will expect to see that processes for identifying and detecting vulnerabilities are i
especially on critical systems or those processing or storing sensitive or classified information.

Rules governing the installation of software by users need to be established and implemented. This control relates to restrictin
of users to install software, especially on local devices (workstations, laptops etc). Installation of software by users raises a num
threats and vulnerabilities including the threat of introduction of malware and the potential breach of software licensing/IPR la
users would not be able to install any software on organisational equipment, however, there may be business or practicality rea
this is not possible. Where full restriction is not possible, it is good practice to “white-list” what software may be installed. The
be checking to see what restrictions have been placed on the installation of software by users. Then, where full restriction is no
implemented, they will want to see evidence that the risks have been fully assessed and where possible, complementary contr
regular software audits have been implemented and are being regularly used.

To minimize the impact of audit activities on operational systems.

Audit requirements and activities involving verification of operational systems need to be carefully planned and agreed on to m
disruptions to the business processes. Whenever carrying out tests and audit activities (e.g. vulnerability scans, penetration tes
operational systems, consideration needs to be given to ensure that operations are not negatively impacted. Additionally, the s
depth of testing must be defined. Any such auditing or testing of operational systems must be through a formal and appropriat
authorised process. The auditor will be looking for evidence that the scheduling of tests and the level of testing is agreed and a
through a formal process.

To ensure the protection of information in networks and its supporting information processing facilities.

Networks must be managed and controlled in order to protect information within systems and applications. Put in simple term
organisation should use appropriate methods in order to ensure it is protecting any information within its systems and applicati
network controls should consider all operations of the business carefully, be adequately and proportionately designed, and imp
according to business requirements, risk assessment, classifications and segregation requirements as appropriate. Some possib
examples of technical controls for consideration may include; Connection control and endpoint verification, firewalls and intrus
detection/prevention systems, access control lists, and physical, logical or virtual segregation. It is also important to enforce the
when connecting to public networks or those of other organisations outside organisational control, to consider the increased r
and to manage these risks with additional controls as appropriate.

You will need to bear in mind that the auditor will be looking to see these implemented controls are effective and managed ap
including the use of formal change management procedures.

Security mechanisms, service levels and management requirements of all network services need to be identified and included
services agreements, whether these services are provided in-house or outsourced. Put into simple terms, the organisation sho
all the various security measures it is taking in order to secure its network services, in its network services agreements. Your au
want to see that the design and implementation of networks takes into account both the business requirements and security
requirements, achieving a balance that is adequate and proportionate to both. They will be looking for evidence of this, along
evidence of a risk assessment.

Groups of information services, users and information systems should be segregated on networks. Wherever possible consider
duties of network operations and computer/system operations e.g. public domains, dept x or y domains. The network design a
Formal transfer
must align to andpolicies,
supportprocedures
informationand controls must
classification be in and
policies place to protect requirements.
segregation the transfer of information through the use of all
communication facilities. Whatever type of communication facility is in use, it is important to understand the security risks invo
relation to the confidentiality, integrity and availability of the information and this will need to take into account the type, natu
and sensitivity
To maintain theorsecurity
classification of the information
of information transferredbeing transferred.
within It is especially
an organization and withimportant to implement
any external entity such policies and p
Information may beis transferred
when information digitally
being transferred orof
out physically andorganisation
or into the agreementsfrommustthird
address the secure
parties. transfer
Different of business information
but complementary controls
the organisation
required to protectandinformation
any external parties.
being Formal from
transferred transfer policies procedures
interception, and technicalmis-routing
copying, modification, controls should be selected,and
and destruction imple
sh
operated,
consideredmonitored,
holisticallyaudited and reviewed
when identifying whichto controls
ensure ongoing
are to beeffective
selected.security protection. Often, communications and transf
and procedures are put in place, without a real understanding of the risks involved which therefore creates vulnerabilities and
compromise. ISO 27002 touches on implementation considerations including consideration of notifications, traceability, escrow
identification standards, chain of custody, cryptography, access control and others.
Any information that is involved in any form of electronic messaging needs to be appropriately protected. Put in simple terms,
electronic messaging, it should be protected to ensure no unauthorised access can be gained The organisation should create a
which sets out which forms of electronic messaging should be used for the different types of information being transferred, e.g
depending on how secure they are. Considerations will also need to be made for voice & fax communications transfer, and phy
transfer (e.g. via postal systems). This should align with access controls and other secure authentication policies and log on pro

A good control describes how the requirements for confidentiality or non-disclosure agreements that reflect the organisation’s
the protection of information must be identified, regularly reviewed and documented. As such the organisation needs to ensu
information that needs to be protected, is done so through the use of confidentiality and non-disclosure agreements.

Agreements are usually specific to the organisation and should be developed with its control needs in mind following the risk a
work. Standard agreements for confidentiality and non-disclosure that may warrant consideration here include:

General non-disclosure and mutual non-disclosure agreements e.g. when sharing sensitive information e.g. about new busines
Customer agreements using standard terms and conditions – expressing confidentiality within the context of the use of produc
any complementary services outlined in a related order form.
Associate/supplier/partner agreements used for small suppliers and independent service providers who the organisation use fo
of services.
Employment related terms (aligned with A.7).
Privacy policies e.g. from email footers.

To ensure that information security is an integral part of information systems across the entire lifecycle. This
also includes the requirements for information systems which provide services over public networks.

Information security related requirements need to be included in any requirements for new information systems or enhancem
existing information systems. This can happen alongside A.6.1.5 as part of the information security in projects and should take
account the value of the information at risk which could align with the information classification scheme in A.8.2.1.

In any new system development or change to existing systems, it is important to understand what the business requirements fo
controls are by doing a risk assessment. This should be done prior to the selection of or commencement of the development o
Security considerations should happen from the earliest possible opportunity to ensure that the correct requirements are iden
before solution selection commences. The security requirements should be documented and agreed so that they can be refere
solution is procured or developed. It is not good practice to select or develop a solution and then assess the level of security ca
afterwards. This often leads to higher risks and costs and may also cause problems in applicable legislation such as GDPR which
encourages a secure by design philosophy and techniques such as Data Protection Privacy Impact Assessments (DPIA). There
numerous websites advocating secure development practices and key principles for consideration such as those advocated by
National Cyber Security Centre (NCSC). ISO 27002 also includes implementation guidance. Any of the principles being followed
documented.

The auditor will be looking to see that security is being considered at all stages of a project lifecycle, for a new system or chang
existing system. They will also expect to see consideration for confidentiality, integrity and availability at a minimum prior to th
or development process commencing.
The information involved in application services passing over public networks need to be protected from fraudulent activity, co
dispute and unauthorised disclosure and modification. For services being provided over a public network, like the internet, it is
to understand the risk levels involved and the business requirements for protecting information. Once again, it is important to
confidentiality, integrity and availability.

When financial transactions or sensitive personal information form part of the service, it is especially important to consider sec
minimise the risk of fraudulent activity where GDPR requirements for encryption and other safeguards need to be the minimum
requirements. Once operational, it is important to ensure that such services are constantly monitored for attack or undesired a
auditor will expect to see the consideration for “how secure” application services over public networks need to be, with decisio
on risk assessment and other legal, regulatory and contractual requirements.

Information involved in application service transactions must be protected to prevent incomplete transmission, mis-routing, un
message alteration, unauthorised disclosure, unauthorised message duplication or replay. Additional protection is likely to secu
application service transactions (not necessarily just financial transactions). These may include; Use of electronic signatures, U
encryption; and Use of secure protocols. The ongoing monitoring of such transactions in as near to real-time manner is also lik
required.
To ensure that information security is designed and implemented within the development lifecycle of
information systems

Rules for the development of software and systems should be established and applied to developments within the organisation
development policy is used to ensure that development environments are themselves secure and that the processes for develo
implementing systems and system changes encourage the use of secure coding and development practices. Such policies will in
showing how security needs to be considered at all stages of the development lifecycle from design through to live implement
Specific coding languages and development tools have different vulnerabilities and require different “hardening” techniques ac
and it is important that these are identified and agreed and developers are made aware of their responsibilities to follow them
policies will address security checkpoints during development; secure repositories; security in version control; application secu
knowledge; and developers’ ability to avoid vulnerabilities, then find and fix them when they occur.

The auditor will be looking here to see that security considerations are appropriate to the level of risk for the systems being de
changed and that those doing the development understand the need to include security consideration throughout the develop
lifecycle. Strong initial screening in hiring for these skills, inlife management and training of resources is essential and practices
programming, peer reviews and independent quality assurance, code reviews and testing are all positive attributes.

Changes to systems within the development lifecycle must be controlled by the use of formal change control procedures. Syste
control procedures should integrate with, be aligned to and support operational change control. Formal change management p
are designed to reduce the risk of accidental or deliberate development of vulnerabilities that may allow systems to be compro
the changes are put live. For system change control, it is important that the system owner understands what changes are being
their system, why and by whom. It is their responsibility to ensure that their systems are not compromised through poor or ma
development. They should therefore be involved in setting the rules for authorisation and pre-live testing and checking. Audit l
required to provide evidence of the correct use of change procedures. ISO 27002 documents many aspects of change control t
be included, ranging from simple documentation of the changes through to consideration of the time for deployment to avoid
business impact. This control like others in A.14 also aligns with documented procedures in A.12.1.2.
When operating platforms are changed, business critical applications need to be reviewed and tested to ensure there is no adv
on the organisational operations or security. When operating system platforms are changed it is commonplace that some appli
have compatibility problems. It is important therefore to test operating system changes in a development or test environment
critical business applications can be checked for compatibility with the changed OS. Procedures for control and testing of opera
changes should follow standard change management control.

Modifications to software packages need to be discouraged, limited to necessary changes and all changes should be strictly con
Vendor supplied software packages are designed for the mass-market and are not really designed for organisations making the
changes to them. In fact most of the time the ability to make such changes is locked out by the vendor and customisation limit
the package. Where open-source software is used, it is far more likely that changes can be made by the organisation, however,
be restricted and controlled to ensure that the changes made do not have an adverse impact on the internal integrity or securi
software.

Principles for engineering secure systems must be established, documented, maintained and applied to any information system
implementation efforts. Secure software engineering principles exist at both general levels and specific to development platfor
coding languages. Wherever development is being carried out, consideration for the selection and application of such principle
considered, assessed, formally documented and mandated. The auditor will want to see that as with many controls, the use of
engineering principles is considered against the risk levels identified and will be looking for evidence to support the choices ma

Organisations need to establish and appropriately protect secure development environments for system development and inte
efforts that cover the entire system development lifecycle. Development environments need to be protected to ensure the ma
accidental development and update of code that may create vulnerabilities or compromise confidentiality, integrity and availab
Protection requirements should be determined from risk assessment, business requirements and other internal and external
requirements including legislation, regulation, contractual agreement or policies. In particular, if any form of live data is used in
development environments it needs to be especially protected and controlled.
The organisation must supervise and monitor the activity of outsourced system development. Where system and software dev
outsourced either wholly or partly to external parties the security requirements must be specified in a contract or attached agr
This is where Annex A 15.1 is important to have correct as well as A.13.2.4 for nondisclosure and confidentiality.

It is also important to supervise and monitor development to gain assurance that organisational standards and requirements fo
within systems is achieved. Depending on how embedded outsource partners are within the organisation, especially if staff are
organisational premises, it is important to include their staff in security awareness training and awareness programmes and
communications. It is critical to ensure that the internal security practices of the outsource partner, e.g. staff vetting, at least m
assurance requirements relevant to the risk levels related to the developments they will be working on.

The auditor will be looking to see that where outsourcing is used, there is evidence of due diligence before, during and after th
engagement of the outsource partner has been conducted and includes consideration for information security provisions.

Testing of security functionality needs to be carried out during development. Specific testing of security functionality for any de
must be carried out and signed-off by an appropriate authority with security competency and responsibility. Security testing ex
outcomes should be documented before testing commences and should be based on business requirements for security. The a
want to see that there is evidence that security specific testing has been carried out in any development that is security relevan

Acceptance testing programs and related criteria must be established for new information systems, upgrades and new versions
acceptance testing, the tests and the criteria for demonstrating a successful test should be designed and developed based on b
requirements prior to tests being carried out. Acceptance testing should also include security testing. The auditor will be lookin
evidence that shows acceptance testing criteria and methods were designed according to business requirements and include p
for security acceptance testing.

To ensure the protection of data used for testing

Test data must be selected carefully, protected and controlled. Test data should ideally be created in a generic form with no rel
system data. However, it is recognised that often live data must be used to perform accurate testing. Where live data is used fo
should be; Anonymised as far as possible; Carefully selected and secured for the period of testing; Securely deleted when testi
complete. Use of live data must be pre-authorised, logged and monitored. The auditor will expect to see robust procedures in
protect data being used in test environments, especially if this is wholly or partly live data.

To ensure protection of the organization’s assets that is accessible by suppliers.

Suppliers are used for two main reasons; one: you want them to do work that you have chosen not to do internally yourself, or
can’t easily do the work as well or as cost effectively as the suppliers.

There are many important things to consider in approach to supplier selection and management but one size does not fit all an
suppliers will be more important than others. As such your controls and policies should reflect that too and a segmentation of
chain is sensible; we advocate four categories of supplier based on the value and risk in the relationship. These range from tho
business critical through to other vendors who have no material impact on your organisation.

Some suppliers are also more powerful than their customers (imagine telling Amazon what to do if you are using their AWS ser
hosting) so it’s pointless having controls and policies in place that the suppliers will not adhere to. Therefore reliance on their s
policies, controls and agreements is more likely – meaning the supplier selection and risk management becomes even more im

In order to take a more forward approach to information security in the supply chain with the more strategic (high value / high
suppliers, organisations should also avoid binary ‘comply or die’ risk transferring practises e.g. awful contracts preventing good
collaboration. Instead we recommend they develop more close working relationships with those suppliers where thigh value in
and assets are at risk, or they are adding to your information assets in some (positive) way. This is likely to lead to improved wo
relationships, and therefore deliver better business results too.

A good policy describes the supplier segmentation, selection, management, exit, how information assets around suppliers are
in order to mitigate the associated risks, yet still enable the business goals and objectives to be achieved. Smart organisations w
their information security policy for suppliers into a broader relationship framework and avoid just concentrating on security p
looking to the other aspects as well.

An organisation may want suppliers to access and contribute to certain high value information assets (e.g. software code devel
accounting payroll information). They would therefore need to have clear agreements of exactly what access they are allowing
they can control the security around it. This is especially important with more and more information management, processing
technology services being outsourced. That means having a place to show management of the relationship is happening; cont
contacts, incidents, relationship activity and risk management etc. Where the supplier is also intimately involved in the organis
may not have its own certified ISMS, then ensuring the supplier staff are educated and aware of security, trained on your polici
also worth demonstrating compliance around

All relevant information security requirements must be in place with each supplier that has access to or can impact the organis
information (or assets that process it). Again this should not be a one size fits all – take a risk based approach around the differ
suppliers involved and work they do.

Working with suppliers that already meet the majority of your organisations information security needs for the services they p
you and have a good track record of addressing information security concerns responsibly is a very good idea – as it will make a
processes much easier. In simple terms, look for suppliers that already have achieved an independent ISO 27001 certification o
equivalent themselves.

It is also important to ensure that the suppliers are being kept informed and engaged with any changes to the ISMS or specifica
around the parts that affect their services. Your auditor will want to see this evidenced – so, by keeping a record of this in your
on-boarding projects or annual reviews it will be easy to do so. Things to include in the supply scope and agreements generally
the work and its scope; information at risk and classification; legal and regulatory requirements e.g. adherence to GDPR and or
applicable legislation; reporting and reviews; non disclosure; IPR; incident management; specific policies to comply with if imp
the agreement; obligations on subcontractors; screening on staff etc. A good standard contract will deal with these points but
sometimes it might not be required, and could be way over the top for the type of supply, or it might not be possible to force a
follow your idea of good practice. Be pragmatic and risk centred in the approach.

This control objective also ties in closely with Annex A.13.2.4 where confidentiality and non-disclosure agreements are the ma
A good control builds on A.15.1.2 and is focused on the ICT suppliers who may need something in addition or instead of the sta
approach. ISO 27002 advocates numerous areas for implementation and whilst these are all good, some pragmatism is needed
The organisation should again recognise its size compared to some of the very large providers that it will sometimes be workin
datacentres & hosting services, banks etc), therefore potentially limiting its ability to influence practices further into the supply
organisation should consider carefully what risks there may be based upon the type of information and communication techno
services that are being provided. For example, if the supplier is a provider of infrastructure critical services, and has access to s
information (e.g. source code for the flagship software service) it should ensure there is greater protection than if the supplier
exposed to publicly available information (e.g. a simple website).

A good control builds on A.15.1.2 and is focused on the ICT suppliers who may need something in addition or instead of the sta
approach. ISO 27002 advocates numerous areas for implementation and whilst these are all good, some pragmatism is needed
The organisation should again recognise its size compared to some of the very large providers that it will sometimes be workin
datacentres & hosting services, banks etc), therefore potentially limiting its ability to influence practices further into the supply
organisation should consider carefully what risks there may be based upon the type of information and communication techno
services that are being provided. For example, if the supplier is a provider of infrastructure critical services, and has access to s
information (e.g. source code for the flagship software service) it should ensure there is greater protection than if the supplier
exposed to publicly available information (e.g. a simple website).

A good control builds on A15.1 and describes how organisations regularly monitor, review and audit their supplier service deliv
Conducting reviews and monitoring is best done based on the information at risk – as a one size approach will not fit all. The o
should aim to conduct its reviews in line with the proposed segmentation of suppliers in order to therefore optimise their reso
make sure that they focus effort on monitoring & reviewing where it will have the most impact. As with A15.1, sometimes ther
for pragmatism – you are not necessarily going to get an audit, human relationship review and dedicated service improvement
if you are a very small organisation. You could however check (say) their annually published SOC II reports and security certifica
remain fit for your purpose.

Evidence of monitoring should be completed based on your power, risks and value, thus allowing your auditor to be able to see
been completed, and that any necessary changes have been managed through a formal change control process.

A good control describes how any changes to the provision of services by suppliers, including maintaining and improving existin
information security policies, procedures and controls, are managed. It takes into account the criticality of business informatio
nature of the change, the supplier type/s affected, the systems and processes involved and a re-assessment of risks. Changes t
services should also take into account the intimacy of the relationship and the organisation’s ability to influence or control chan
supplier.

Depending on the nature of the change (i.e. for more material changes) there may be a broader requirement to align with A.6.
information Security in Project Management.

To ensure a consistent and effective approach to the management of information security incidents, including
communication on security events and weaknesses.
A good control describes how management establish responsibilities and procedures in order to ensure a quick, effective and o
response to address weaknesses, events and security incidents. In simple terms an incident is where some form of loss has occ
around confidentiality, integrity or availability. An example is where a window was left open and a thief stole an important file
the desk…….Following that thread, an event is where the window was left open but nobody stole the file. A weakness is that t
is easily broken or old and could be an obvious place for break-in. A weakness is also a common risk management or improvem
opportunity.

The procedures for incident, event and weakness response planning will need to be clearly defined in advance of an incident o
and been approved by your leadership. Those procedures are pretty easy to develop because the remainder of this Annex A co
them out. Your auditor will expect to see all of these formal, documented procedures in place, and evidence that they are wo

A good control here ensures that information security incidents and events can be reported through suitable management cha
soon as possible.

Employees and associated interested parties (e.g. suppliers) need to be made aware of their obligations to report security incid
you should cover that off as part of your general awareness and training. In order to do this well they will need to have awaren
exactly what constitutes an information security weakness, event or incident so be clear about that, based on the simple exam
If an information security event occurs or is thought to have occurred, it must be reported immediately to the nominated infor
security administrator and that needs to be documented accordingly.

Some of the possible reasons for reporting a security incident include; ineffective security controls; assumed breaches of inform
integrity or confidentiality, or availability issues e.g. not being able to access a service.

The auditor will want to see and will be sampling for evidence of awareness of what constitutes a weakness, event or incident
general staff, and the awareness of incident reporting procedures and responsibilities.

This control simply builds on incidents and events but might be treated slightly differently once reported (see A.16.1.4)
It is essential for employees to be aware of the fact that when discovering a security weakness, they must not attempt to prove
weakness, as testing it may be interpreted as a misuse of the system, whilst also risking damaging the system and its stored inf
causing security incidents!

Information security events must be assessed and then it can be decided if they should be classified as information security inc
events of weaknesses. Once a security event has been reported and subsequently logged, it will then need to be assessed in o
determine the best course of action to take. This action must aim to minimise any compromise of the availability, integrity or
confidentiality of information and prevent against further incidents. Ideally it will have minimum impact to other users of the
Consideration of exactly who needs to be made aware of the incident, internally, customers, suppliers, regulators can take plac
part of the lifecycle too.

GDPR and the Data Protection Act 2018 means that some information security incidents relating to personal data need to be re
the Supervisory Authority too, so your controls should also tie in these considerations to meet regulatory requirements and av
duplication or gaps in work.
It is always good to assign owners, be clear on actions and timescales, and as with everything for ISO 27001, retain the informa
audit purposes (also essential if you have other stakeholders and regulators to consider). The individual placed in charge of dea
the security event will be responsible for restoring a normal level of security whilst also;

collecting evidence as soon as possible after the occurrence;

conducting an information security forensics analysis (grand term but at least being clear on root cause and related aspects or
happened and who was involved, why etc);
escalation, if required, for example to relevant regulators;
ensuring all that all involved response activities are properly logged for later analysis;
communicating the existence of the information security incident or any relevant details to the leadership for them to be furth
communicated to various individuals or organisations on a need-to-know basis; and
dealing with information security weaknesses found to cause or contribute to the incident.

This is an importance control, and your policy needs to demonstrate that knowledge gained from analysing and resolving inform
security incidents will be used to help reduce the likelihood or impact of any future incidents.

As part of the commitment to continuous service improvement, you should ensure that you learn from the lessons of any secu
incident to therefore help evolve and adapt the ISMS to meet the changing landscape that is worked in.

Once an incident has been resolved, it should be placed into a status of review and learning, where the lead responder for that
will discuss any changes required to the processes of the ISMS policies as a result. Any relevant recommendations should then
the ISMS Board for further discussion.

Once the review and learning has been completed, updates have been made to the policies as required, the relevant staff mus
notified and re-trained if required, and the cycle of information security awareness and education continues.

The organisation has to define and apply controls for the identification, collection, acquisition and preservation of information,
be used as evidence, especially if there is criminal or civil proceedings likely to happen from the incident.
Where the organisation suspects or knows that a security incident may result in legal or disciplinary action, they should carry o
collection of evidence carefully, ensure a good chain of custody and avoid any threat of being caught out by poor management

It’s sensible to tie information security incident management clearly to disciplinary procedures too. Everyone should know to t
precautions whilst also being clear on the consequences for those who fail to take it seriously.
The organisation must determine its requirements for information security and the continuity of information security managem
adverse situations, e.g. during a crisis or disaster. The best ISMS’s will already have broader Annex A controls that mitigate agai
to implement a disaster recovery process or business continuity plan in line with A.17. Despite that effort, more significant dis
incidents may still happen so planning for them is important. What happens when a major data centre with your information a
applications in it becomes unavailable? What happens when a major data breach occurs, a ransomware attack is made or a ke
the business is out of action, or perhaps Head Office suffers a major flooding……..?

Having considered the various events and scenarios that need to be planned for, the organisation can then document the plan
whatever detail is required to demonstrate it understands those issues and the steps required to address them.

ISO 22301 offers a more structured approach to business continuity that dovetails very elegantly with the main requirements o
27001.

The organisation needs to establish, document, implement and maintain processes, procedures and controls to ensure the req
of continuity for information security during a disruptive situation. Once requirements have been identified, the organisation m
implement policies, procedures and other physical or technical controls that are adequate and proportionate in order to meet
requirements. Description of the responsibilities, activities, owners, timescales, mitigating work to be undertaken (beyond risks
policies already in operation e.g. crisis communications). A management structure and relevant escalation trigger points should
identified to ensure that if and when an event increases in severity the relevant escalation to the appropriate authority is made
and in a timely manner. It should also be made clear when there is a return to business as usual and any BCP processes stop

The organisation must verify the established and implemented information security continuity controls at regular intervals in o
ensure that they are valid and effective during these situations. The controls implemented for information security continuity m
tested, reviewed and evaluated periodically to ensure they are maintained against changes in the business, technologies and ri
levels.The auditor will want to see that there is evidence of; Periodic testing of plans and controls; Logs of plan invocations and
taken through to resolution and lessons learnt; and Periodic review and change management to ensure that plans are maintain
change.

A good control describes how information processing facilities are implemented with redundancy sufficiency to meet availabili
requirements. Redundancy refers to implementing, typically, duplicate hardware to ensure availability of information processin
The principle is that if one or more items fail, then there are redundant items that will take over. Critical to this is the testing of
components and systems periodically to ensure that fail-over will be achieved in a reasonable time-frame. Redundant compon
be protected at the same level or greater than the primary components. Many organisations use cloud based providers so they
to ensure redundancy is addressed effectively in their contracts with suppliers and as part of the policy in A.15.

The auditor will expect to see that testing is carried out on a periodic basis, where redundant components & systems are in pla
the control of the organisation.
A good control describes how all relevant legislative statutory, regulatory, contractual requirements, and the organisation’s app
meet these requirements should be explicitly identified, documented and kept up to date for each information system and the
organisation. Put in simple terms, the organisation needs to ensure that it is keeping up to date with and documenting legislati
regulation that affects achievement of its business objectives and the outcomes of the ISMS.

It is important that the organisation understands the legislation, regulation and contractual requirements with which it must co
these should be centrally recorded in register to allow for ease of management and coordination. The identification of what is
largely depend on; Where the organisation is located or operates; What the nature of the organisation’s business is; and The na
information being handled within the organisation. The Identification of the relevant legislation, regulation and contractual req
is likely to include engagement with legal experts, regulatory bodies and contract managers.

This is an area that often catches organisations out as there is generally far more legislation and regulation impacting the organ
than is first considered. The auditor will be looking to see how the organisation has identified and recorded its legal, regulatory
contractual obligations; the responsibilities for meeting such requirements and any necessary policies, procedures and other co
required for meeting the controls. Additionally, they will look to see that this register is maintained on a regular basis against an
change – especially in legislation across common areas that they would expect any organisation to be impacted by.
A good control describes how the appropriate procedures ensure compliance with legislative, regulatory and contractual requi
related to intellectual property rights and use of proprietary software products. Put into simple terms, the organisation should
appropriate procedures which ensure it complies with all its requirements, whether they are legislative, regulatory or contractu
to its use of software products or intellectual property rights.

There are two aspects of IPR management to consider; Protection of IPR owned by the organisation; and Prevention of misuse
of other’s IPR. The former will also be addressed with A.13.24 for non-disclosure and confidentiality agreements, where we als
firms manage their broader master contracts with third parties from, and also within A.15 for supply chain specifically. For staff
Terms and conditions of employment will be covering IPR too.

Policies, processes and technical controls are likely to be needed for both of these aspects. Within asset registers and acceptab
policies it is likely that IPR considerations will need to be made – e.g. where an asset is or contains IPR protection of this asset m
consider the IPR aspect. Controls to ensure that only authorised and licensed software are in use within the organisation shoul
regular inspection and audit.

The auditor will want to see that registers of licenses owned by the organisation for use of others’ software and other assets ar
kept and updated. Of particular interest to them will be ensuring that where licenses include a maximum number of users or in
that this number is not exceeded and user and installation numbers are audited periodically to check compliance. The auditor
looking at how the organisation protects its own IPR, which might include; Data loss and prevention controls; Policies and awar
programmes targeting user education; or Non-disclosure and confidentiality agreements that continue post termination of em

A good control describes how records are protected from loss, destruction, falsification, unauthorised access and unauthorised
accordance with the legislatory, regulatory, contractual and business requirements. Different types of record will likely require
levels and methods of protection. It is critical that records are adequately and proportionality protected against loss, destructio
falsification, unauthorised access or release. The protection of records must comply with any relevant legislation, regulation or
obligations. It is especially important to understand how long records must, should or could be kept for and what technical or p
issues might affect these over time – bearing in mind that some legislation might trump others for retention and protection. Th
will be checking to see that considerations for the protection of records has been made based on business requirements, legal,
and contractual obligations.
A good control describes how privacy and protection of personally identifiable information is assured for relevant legislation an
regulation. Any information handled that contains personally identifiable information (PII) is likely to be subject to the obligatio
legislation and regulation. PII is especially likely to have high requirements for confidentiality and integrity, and in some cases a
as well (e.g. health information, financial information). Under some legislation (e.g. the GDPR) some types of PII are defined as
additionally “sensitive” and require further controls to ensure compliance.

It is important that awareness campaigns are used with staff and stakeholders to ensure a repeated understanding of individua
responsibility for protecting PII and privacy. The auditor will be looking to see how PII is handled, if the appropriate controls ha
implemented, are they being monitored, reviewed and where necessary improved. They will also be looking to check that hand
requirements are being met, and audited suitably. Additional responsibilities exist too, for example GDPR will expect a regular
areas where personal data is at risk. Smart organisations will tie these audits up alongside their ISO 27001 audits and avoid dup
gaps.
A good control describes how cryptographic controls are used in compliance with all relevant agreements, legislation and regu
use of cryptographic technologies is subject to legislation and regulation in many territories and it is important that an organisa
understands those that are applicable and implements controls and awareness programmes that ensure compliance with such
requirements. This is especially true when cryptography is transported or used in territories other than the organisation’s or us
place of residence or operation. Trans-border import/export laws may include requirements relating to cryptographic technolo
usage. The auditor will be looking to see that considerations for the appropriate regulation of cryptographic controls have been
relevant controls and awareness programmes implemented to ensure compliance.
Applicabe or technical or Manually

Manual

Manual

Manual

Technical
Manual

Manual

Manual

Manual

Manual

Technical
Manual

Manual

Manual

Manual
Manual

Manual

Manual

Manual

Manual

Manual

Manual
Technical

Technical

Technical

Technical

Manual

Manual

Technical
Technical

Manual

Technical

Technical

Manual

Manual

Manual
Manual

Technical

Manual

Manual

Manual
Manual

Manual

Manual

Manual

Manual

Manual

Manual
Manual

Manual

Manual

Technical
Manual

Manual

Manual

Manual

Manual

Manual
Manual

Manual

Manual

Manual

Manual
Manual

Manual

Manual

Manual
Manual

Manual

Manual
Manual

Manual

Technical
Manual

Manual

Manual

Manual

Technical
Technical

Manual

Manual

Technical

Technical

Technical

Technical

Technical

Manual
Technical

Technical

Manual

Technical

Manual
Manual

Technical

Manual

Technical

Technical

Technical

Manual

Manual
Manual

Manual

Technical

Technical
Manual

Manual

Manual

Manual

Manual
Manual

Manual

Manual

Manual
Manual

Manual

Manual

Manual

Technical

Manual
Manual

Manual
Manual

Manual

Manual

Manual

Manual
Technical

Technical

Technical

Technical
Technical

Technical

Technical
Manual

Manual

Manual

Manual
Manual

Manual

Manual
Manual

Manual