Version Date Author

1.0 ### Neil Shepherd, SRC GmbH &

Andrew Hutchins, NCC Group
1.1 11 Sep 2020 Alvaro Rosa, NCC Group
Description
First released version.

Minor corrections
Introduction
The purpose of this workbook is to help an auditee prepare for a remote audit. The Auditee Preparation worksheet include
SAS-SM and informaiton on the type of information that the auditors will expect to review.

Auditees are expected to review this workbook, together with the following:
- GSMA SAS Remote Audit Policy,
- FS.08 SAS-SM Standard,
- FS.09 SAS-SM Methodology,
- FS.17 SAS Consolidated Security Requirements, and
- FS.18 SAS Consolidated Security Guidelines.

This workbook does not replace the need for the auditee to have a full understanding of the FS documents.

How to Complete This Workbook (Auditee Guidance)

Offline Document Review Readiness

The auditors will need to have access to the policies and procedures that relate to the SAS-SM scope of compliance. The d
to the Document List Worksheet.

In addition, as this phase will be undertaken offline, the auditors need to understand how you have addressed each requir
you have to ensure compliance with the FS.17 requirements).

To be completed:
Auditee Preparation Worksheet columns F and G.
Document List columns F and G (for those documents marked with a 'Yes' in column D)

Online Evidence Readiness

The auditors will need to review evidences to demonstate the controls are working as per described in the policies and pro
what types of evidences the auditors will be looking for. During the preparation and planning meetings, the auditee must d
presenting these to the auditors. Within the Auditee Preparation worksheet, column J should be completed to describe ho
constraints (e.g. physical verification within sections 5, 6 and 10) will be marked in the report and require verification once

To be completed:
Auditee Preparation Worksheet columns J.
Document List columns F and G (for those evidences marked with a 'Yes' in column E)
 GSMA FS.17 SAS Consolidated Security Requirements (CSR) version 4.0

Section Sub-Sect Sub-Sect Desc Req.

1 - Policy, Strategy, and 1.1 Policy 1.1.1

Documentation

1 - Policy, Strategy, and 1.1 Policy 1.1.2

Documentation

1 - Policy, Strategy, and 1.2 Strategy 1.2.1

Documentation
1 - Policy, Strategy, and 1.3 Business Continuity 1.3.1
Documentation Planning

1 - Policy, Strategy, and 1.4 Internal audit and 1.4.1

Documentation control
2 - Organisation and Responsibility 2.1 Organisation 2.1.1

2 - Organisation and Responsibility 2.1 Organisation 2.1.2

2 - Organisation and Responsibility 2.2 Responsibilities 2.2.1

2 - Organisation and Responsibility 2.2 Responsibilities 2.2.2

2 - Organisation and Responsibility 2.2 Responsibilities 2.2.3

2 - Organisation and Responsibility 2.2 Responsibilities 2.2.4

2 - Organisation and Responsibility 2.3 Incident response 2.3.1
and reporting

2 - Organisation and Responsibility 2.4 Contracts and 2.4.1

liabilities

3 - Information 3.1 Classification 3.1.1

3 - Information 3.2 Data and media 3.2.1

handling
 3.2.2

4 - Personnel Security 4.1 Security in job 4.1.1

description
4 - Personnel Security 4.2 Recruitment 4.2.1
screening

4 - Personnel Security 4.3 Acceptance of 4.3.1

security rules

4 - Personnel Security 4.3 Acceptance of 4.3.2

security rules

4 - Personnel Security 4.3 Acceptance of 4.3.3

security rules

4 - Personnel Security 4.4 Incident response 4.4.1

and reporting

4 - Personnel Security 4.4 Incident response 4.4.2

and reporting
4 - Personnel Security 4.5 Contract termination 4.5.1

5 - Physical Security 5.1 Security plan 5.1.1

5 - Physical Security 5.2 Physical protection 5.2.1

5 - Physical Security 5.2 Physical protection 5.2.2

5 - Physical Security 5.3 Access control 5.3.1

5 - Physical Security 5.3 Access control 5.3.2

5 - Physical Security 5.4 Security Staff 5.4.1

5 - Physical Security 5.5 Internal audit and 5.5.1
control

6 - Certificate and key management 6.1 Classification 6.1.1

6 - Certificate and key management 6.2 Roles and 6.2.1

responsibilities
6 - Certificate and key management 6.2 Roles and 6.2.2
responsibilities
6 - Certificate and key management 6.3 Cryptographic key 6.3.1
specification

6 - Certificate and key management 6.4 Cryptographic key 6.4.1

management
6 - Certificate and key management 6.4 Cryptographic key 6.4.2
management

6 - Certificate and key management 6.4 Cryptographic key 6.4.3

management

6 - Certificate and key management 6.5 Auditability and 6.5.1

accountability
6 - Certificate and key management 6.6 GSMA Public Key 6.6.1
Infrastructure (PKI)
Certificates

6 - Certificate and key management 6.6 GSMA Public Key 6.6.2

Infrastructure (PKI)
Certificates

6 - Certificate and key management 6.6 GSMA Public Key 6.6.3

Infrastructure (PKI)
Certificates

6 - Certificate and key management 6.6 GSMA Public Key 6.6.4

Infrastructure (PKI)
Certificates

7 - Sensitive Process data management 7.1 Data transfer 7.1.1

7 - Sensitive Process data management 7.2 Sensitive data 7.2.1
access, storage and
retention

7 - Sensitive Process data management 7.2 Sensitive data 7.2.2

access, storage and
retention

7 - Sensitive Process data management 7.2 Sensitive data 7.2.3

access, storage and
retention
7 - Sensitive Process data management 7.4 Auditability and 7.4.1
accountability
7 - Sensitive Process data management 7.4 Auditability and 7.4.2
accountability

7 - Sensitive Process data management 7.4 Auditability and 7.4.3

accountability

7 - Sensitive Process data management 7.5 Duplicate production 7.5.1

7 - Sensitive Process data management 7.6 Data integrity 7.6.1

7 - Sensitive Process data management 7.7 Internal audit and 7.7.1

control
8 - SM-DP, SM-SR, SM-DP+ and SM-DS 8.1 SM-DP, SM-SR, SM- 8.1.1
Service Management DP+ and SM-SR
Service

8 - SM-DP, SM-SR, SM-DP+ and SM-DS 8.1 SM-DP, SM-SR, SM- 8.1.2
Service Management DP+ and SM-SR
Service

8 - SM-DP, SM-SR, SM-DP+ and SM-DS 8.1 SM-DP, SM-SR, SM- 8.1.3
Service Management DP+ and SM-SR
Service

8 - SM-DP, SM-SR, SM-DP+ and SM-DS 8.1 SM-DP, SM-SR, SM- 8.1.4
Service Management DP+ and SM-SR
Service
8 - SM-DP, SM-SR, SM-DP+ and SM-DS 8.2 Remote Entity 8.2.1
Service Management Authentication

8 - SM-DP, SM-SR, SM-DP+ and SM-DS 8.3 Audit trails 8.3.1

Service Management
8 - SM-DP, SM-SR, SM-DP+ and SM-DS 8.3 Audit trails 8.3.2
Service Management

10 - Computer and network 10.1 Policy 10.1.1

management

10 - Computer and network 10.2 Segregation of duties 10.2.1

management
10 - Computer and network 10.3 Access control 10.3.1
management

10 - Computer and network 10.3 Access control 10.3.2

management
10 - Computer and network 10.3 Access control 10.3.3
management
10 - Computer and network 10.3 Access control 10.3.4
management
10 - Computer and network 10.4 Network Security 10.4.1
management

10 - Computer and network 10.4 Network Security 10.4.2

management

10 - Computer and network 10.4 Network Security 10.4.3

management
10 - Computer and network 10.4 Network Security 10.4.4
management

10 - Computer and network 10.4 Network Security 10.4.5

management

10 - Computer and network 10.5 System Security 10.5.1 (i)

management
10 - Computer and network 10.5 System Security 10.5.1 (ii)
management

10 - Computer and network 10.5 System Security 10.5.1 (iii)

management

10 - Computer and network 10.5 System Security 10.5.1 (iv)

management
10 - Computer and network 10.5 System Security 10.5.1 (v)
management

10 - Computer and network 10.5 System Security 10.5.1 (vi)

management
10 - Computer and network 10.5 System Security 10.5.1 (vii)
management

10 - Computer and network 10.5 System Security 10.5.1 (viii)

management

10 - Computer and network 10.5 System Security 10.5.2

management

10 - Computer and network 10.6 Audit and monitoring 10.6.1

management
10 - Computer and network 10.7 External facilities 10.7.1
management management

10 - Computer and network 10.8 Internal audit and 10.8.1

management control
10 - Computer and network 10.9 Software 10.9.1
management Development
urity Requirements (CSR) version 4.0

Description

A clear direction shall be set and supported by a documented

security policy which defines the security objectives and the rules
and procedures relating to the security of the SP, sensitive
information and asset management.

Employees shall understand and have access to the policy and its
application should be checked periodically.

A coherent security strategy must be defined based on a clear

understanding of the risks. The strategy shall use periodic risk
assessment as the basis for defining, implementing and updating the
site security system. The strategy shall be reviewed regularly to
ensure that it reflects the changing security environment through
ongoing re-assessment of risks.
Business continuity measures must be in place:
to ensure an appropriate level of availability
to enable response and recovery in the event of a disaster.

The overall security management system shall be subject to a

rigorous programme of internal monitoring, audit and maintenance
to ensure its continued correct operation.
To successfully manage security, a defined organisation structure
shall be established with appropriate allocation of security
responsibilities.

The management structure shall maintain and control security

through a cross-functional team that co-ordinates identification,
collation, and resolution, of security issues, independent of the
business structure.

A security manager shall be appointed with overall responsibility for

the issues relating to security in the SP.

Clear responsibility for all aspects of security, whether operational,

supervisory or strategic, must be defined within the business as part
of the overall security organization.

Asset protection procedures and responsibilities shall be

documented throughout the SP.

Clear security rules shall govern the manner in which employees

engaged in such activities shall operate within the SP. Relevant
guidelines should be in place and communicated to all relevant staff.
An incident response mechanism shall be maintained that includes a
process for the investigation and mitigation of:
(i) accidental or deliberate breach of internal
regulations and procedures
(ii) suspected or detected compromise of systems, or
receipt of notification of system vulnerabilities
(iii) physical or logical penetration of the site
(iv) denial of service attacks on components (where
applicable)

In terms of contractual liability, responsibility for loss shall be

documented. Appropriate controls and insurance shall be in place.

A clear structure for classification of information and other assets

shall be in place with accompanying guidelines to ensure that assets
are appropriately classified and treated throughout their lifecycle.

Access to sensitive information and assets must always be governed

by an overall ‘need to know’ principle.
Guidelines shall be in place governing the handling of data and
other media, including a clear desk policy. Guidelines should
describe the end-to-end ‘lifecycle management’ for sensitive assets,
considering creation, classification, processing, storage, transmission
and disposal.

Security responsibilities shall be clearly defined in job descriptions.

An applicant, and employee, screening policy shall be in place where
local laws allow.

All recruits shall sign a confidentiality agreement.

Employees shall read the security policy and record their

understanding of the contents and the conditions they impose.

Adequate training in relevant aspects of the security management

system shall be provided on an ongoing basis.

Reporting procedures shall be in place where a breach of the

security policy has been revealed.

A clear disciplinary procedure shall be in place in the event that a

staff member breaches the security policy.
Clear exit procedures shall be in place and observed with the
departure of each Employee.

Layers of physical security control shall be used to protect the SP

according to a clearly defined and understood strategy. The strategy
shall apply controls relevant to the assets and risks identified
through risk assessment.

The strategy shall be encapsulated in a security plan that:

- defines a clear site perimeter / boundary
- defines one or more levels of secure area within the
boundary of the site perimeter
- maps the creation, storage and processing of sensitive
assets to the secure areas
- defines physical security protection standards for each
level of secure area

The protection standards defined in the security plan shall be

appropriately deployed throughout the site, to include:
- physical protection of the building and secure areas
capable of resisting attack for an appropriate period
- deterrent to attack or unauthorized entry
- mechanisms for early detection of attempted attack
against, or unauthorized entry into, the secure areas at
vulnerable points
- control of access through normal entry / exit points into
the building and SP to prevent unauthorized access
- effective controls to manage security during times of
emergency egress from the secure area and building
- mechanisms for identifying attempted, or successful,
unauthorized access to, or within the site
- mechanisms for monitoring and providing auditability
 capable of resisting attack for an appropriate period
- deterrent to attack or unauthorized entry
- mechanisms for early detection of attempted attack
against, or unauthorized entry into, the secure areas at
vulnerable points
- control of access through normal entry / exit points into
the building and SP to prevent unauthorized access
- effective controls to manage security during times of
emergency egress from the secure area and building
- mechanisms for identifying attempted, or successful,
unauthorized access to, or within the site
- mechanisms for monitoring and providing auditability
of, authorised and unauthorised activities within the SP.
Controls deployed shall be clearly documented and up-to-date.

Clear entry procedures and policies shall exist which cater for the
rights of Employees, visitors and deliveries to enter the SP. These
considerations shall include the use of identity cards, procedures
governing the movement of visitors within the SP, delivery/dispatch
checking procedures and record maintenance.
Access to each secure area shall be controlled on a ‘need to be
there’ basis. Appropriate procedures shall be in place to control,
authorise, and monitor access to each secure area and within secure
areas.

Security staff are commonly employed by suppliers. Where this is

the case the duties shall be clearly documented and the necessary
tools and training shall be supplied.
Physical security controls shall be subject to a rigorous programme
of internal monitoring, audit and maintenance to ensure their
continued correct operation.

Keys and certificates shall be classified as sensitive information.

Logical, physical, personnel and procedural controls shall be applied
to ensure that appropriate levels of confidentiality, integrity and
availability are applied.

Responsibilities and procedures for the management of certificates

and cryptographic shall be clearly defined.
Auditable dual-control shall be applied to sensitive steps of key
management.
Technical specifications for cryptographic keys and certificates shall
be selected that are:
• compliant with relevant or applicable standards
or
• of an appropriate level to the asset(s) protected, based on risk and
lifespan.

Cryptographic keys, certificates and activation data shall be

generated, exchanged, stored, backed-up and destroyed securely.
The cryptographic key management process shall be documented
and cover the full lifecycle of keys & certificates.

The cryptographic computation for certificate generation

(derivations, random generations) and storage of keys involved in
the protection of the sensitive data (i.e. Class 1 data) shall rely on
hardware security modules (HSM) that are FIPS 140-2 level 3
certified.

Key management activities shall be controlled by an audit trail that

provides a complete record of, and individual accountability for, all
actions.
Supplier certificates used as part of any GSMA PKI shall be signed by
a CA authorized by and acting on behalf of the GSMA

PKI certificate private keys shall only ever be installed and used for
signing at sites:
(i) That are agreed with the GSMA.
(ii) That are SAS certified with the appropriate scope.
(iii) In accordance with the certificate policy.

PKI certificate key pairs shall only ever be transferred and installed
to a different operational site:
(i) With the prior agreement of the GSMA.
(ii) Where the new operational site is SAS certified with the
appropriate scope.
(iii) In accordance with the certificate policy.
(iv) By a mechanism that ensures an appropriate level of security
for the transfer of the sensitive assets.

Where auditees make use of the same PKI certificate private key at
multiple sites, in addition to the requirements of 6.6.2 and 6.6.3:
(i) A single, nominated, site within the auditee organization shall be
responsible for control and issue of the certificate key pair.
(ii) All transfer of certificate private keys shall originate from the
nominated site.
(iii) Controls shall be in place to prevent certificate private keys
being transferred except under the control of the nominated site.
(iv) All transfer of certificate private keys shall be recorded and
auditable.

Sites shall take responsibility to ensure that electronic data transfer

between themselves and other third parties is appropriately
secured.
Sites shall prevent direct access to sensitive process data where it is
stored and processed.
User access to sensitive data shall be possible only where absolutely
necessary. All access must be auditable to identify the date, time,
activity and person responsible.
System and database administrators may have privileged access to
sensitive data. Administrator access to data must be strictly
controlled and managed. Administrative access to data shall only
take place where explicitly authorized and shall always be
irreversibly logged.

Data shall be stored protected appropriate to its classification.

Data retention policies shall be defined, monitored and enforced.

The sensitive process shall be controlled by an audit trail that
provides a complete record of, and individual accountability for the
lifecycle of information assets to ensure that: all assets created,
processed and deleted are completely accounted for access to
sensitive data is auditable responsible individuals are traceable and
can be held accountable
The audit trail shall be protected in terms of integrity and the
retention period must be defined. The audit trail shall not contain
sensitive data.

Auditable dual-control and 4-eyes principle shall be applied to

sensitive steps of data processing.

Controls shall be in place to prevent duplicate production.

Controls shall be in place to ensure that the same, authorized, data
from the correct source is used for the sensitive process and
supplied to the customer.

Sensitive data controls shall be subject to a rigorous programme of

internal monitoring, audit and maintenance to ensure their
continued correct operation.
Systems used for the remote provisioning, management of eUICCs
and management of Profiles shall support the secure interfaces as
defined in SGP.01 [6], SGP.02 [7], SGP.21 [8] and/or SGP.22 [9] as
applicable.

Exchange of data within the SM-DP, SM-SR, SM-DP+ or the SM-DS IT

system shall be secured to the level required by its asset
classification.

The SM-DP, SM-SR, SM-DP+ and SM-DS must prevent cross-

contamination of assets between different customers.

Multi-tenant SM-DP, SM-SR, SM-DP+ and SM-DS solutions on the

same physical hardware shall ensure customer data is logically
segregated between different customers.
All authorized entities in the SM-DP, SM-SR, SM-DP+ and SM-DS
processes shall be authenticated by appropriate authentication
protocols for example, SM-SR, SM-DP, SM-DP+, SM-DS, MNO.

The SP shall be logged in an audit trail that provides a complete

record of, and individual accountability for:
Profile Management, Platform Management, IT system and eUICC
Management procedures, events management, and communication
with other entities through the secure interfaces. Access to sensitive
data
The audit trail shall be managed in accordance with the
requirements of 7.4.

A documented IT security policy shall exist which shall be well

understood by employees.

Roles and responsibilities for administration of computer systems

shall be clearly defined.
Administration of systems storing or processing sensitive data shall
not normally be carried out by users with regular operational
responsibilities in these areas.
Roles for review of audit logs for sensitive systems should be
separated from privileged users (e.g. administrators).
Physical access to sensitive computer facilities shall be controlled.

An access control policy shall be in place and procedures shall

govern the granting of access rights with a limit placed on the use of
special privilege users. Logical access to IT services shall be via a
secure logon procedure.
Passwords shall be used and managed effectively.
Strong authentication shall be deployed where remote access is
granted.
Systems and data networks used for the processing and storage of
sensitive data shall be housed in an appropriate environment and
logically or physically separated from insecure networks.

Data transfer between secure and insecure networks must be

strictly controlled according to a documented policy defined on a
principle of minimum access.

The system shall be implemented using appropriately configured

and managed firewalls incorporating appropriate intrusion
detection systems.
Controls shall be in place to proactively identify security weaknesses
and vulnerabilities and ensure that these are addressed in
appropriate timescales.

Systems providing on-line, real-time services shall be protected by

mechanisms that ensure appropriate levels of availability (e.g. by
protecting against denial-of-service attacks).

Systems configuration and maintenance: Security requirements of

systems shall be identified at the outset of their procurement and
these factors shall be taken into account when sourcing them.
Systems configuration and maintenance: System components and
software shall be protected from known vulnerabilities by having
the latest vendor-supplied security patches installed.

Systems configuration and maintenance: System components

configuration shall be hardened in accordance with industry best
practice.

Systems configuration and maintenance: Change control processes

and procedures for all changes to system components shall be in
place.
Systems configuration and maintenance: Processes shall be in place
to identify security vulnerabilities and ensure the associated risks
are mitigated.

Systems configuration and maintenance: Comprehensive measures

for prevention and detection of malware and viruses shall be
deployed across all vulnerable systems.
Systems configuration and maintenance: Unattended terminals shall
timeout to prevent unauthorised use and appropriate time limits
should be in place.

Systems configuration and maintenance:

Decertification/decommissioning of assets (such as IT systems) used
as part of the SP shall be documented and performed in a secure
manner.

Back-up copies of critical business data shall be taken regularly.

Back-ups shall be stored appropriately to ensure confidentiality and
availability.

Audit trails of security events shall be maintained and procedures

established for monitoring use.
If any sub-contracted external facilities or management services are
used, appropriate security controls shall be in place. Such facilities
and services shall be subject to the requirements stated in this
document.

IT security controls shall be subject to a rigorous programme of

internal monitoring, audit and maintenance to ensure their
continued correct operation.
The software development processes for the SM-DP, SM-SR, SM-
DP+ or SM-DS shall follow industry best practices for development
of secure systems.
 Preparation for Offline Documentation Review
(A.6 of Annex A to GSMA SAS Remote Audit Policy)

Auditee Self-Assessment Statement

(description of how the requirement and expected control
are being met)
or Offline Documentation Review
to GSMA SAS Remote Audit Policy)

Auditee Documentation
(reference to the document list)
 How the Auditors Will Assess Compliance

Expected Control

There is an Information Security Policy in place, which is the primary

document for governance across all aspects of the SAS-SM
environment.

Policies are accessible by all employees involved in SAS-SM and

there is a mechanism to review documents in the policy framework
on a regular basis (at least annually) and notify employees of
updates/new releases.

There is a process to record employees receipt and acknowledge

understanding of policies.
There is a risk management policy in place supported by a
methodology.

Regular risk assessments are performed for SAS-SM. Risks are

recorded in a risk register, allocated ownership and actions taken to
mitigate the risks. Risk management is reported to the cross-
functional security forum (CFSF; section 2.2.2)

A security strategy is in place, either as a stand-alone document or

through the actions recorded in the risk register.
A security strategy is in place, either as a stand-alone document or
through the actions recorded in the risk register.

There is a business continuity plan in place that reflects the specific

availability requirements of the SP and customer SLAs.

The BCP is based on risks and/or business impact assessments,

which are performed on a regular basis (e.g. annually). The BCP
must address specific issues, including:
- definition of critical incidents?
- processes for the management of scenarios?
- processes for ensuring continuity of operations?
- management of customer contact and customer data?
- maintenance of security system integrity?
- maintenance of production processes integrity?

The BCP is subject to periodic testing (e.g. annual). Testing should

include scenario-based testing covering:
- scenario is defined that would lead to an incident?
- key personnel presented with scenario?
- desktop exercise is performed?
- evaluation of BCP effectiveness to handle scenario?
- identification of improvements/lessons learnt?
- mechanism to update plan based on improvements?

There is an established programme for internal checks and audits,

which list all of the checks/audits to be performed, together with
the frequency (e.g. daily, weekly, fortnightly, monthly, quarterly,
semi-annual, annual, bi-annual (two years)). If using a 3 lines of
defence model, the line performing the check is listed in the
programme.

For each check/audit activity, the following is documented:

- purpose,
- scope (including period covered and population)
- objective,
- methodology for testing
- details of testing undertaken
- findings / observations
- observations
- conclusion
The outcome of checks/audits are reported promptly and actions to
address recommendations tracked.

The checks are performed by appropriately trained personnel,

whom are independent of the team operating the control.
There is an approved organisational structure for the SM solution.

There is a cross-functional security forum (steering committee) that

is represented by all parts of the business involved in the SM
solution and includes representation of senior management.

The group meets on a regular basis to provide governance over the

security posture of the environment.

You have defined an individual with overall responsibility for the SM

environment.

All roles and responsibilities relating to the SAS-SM environment are

defined and clearly documented, either in job descriptions (where
security is a significant aspect of the role) or listed in a document
(where security is not a significant aspect).

Roles should be communicated and accepted by the individuals (if

the responsibilities are additional to their normal job role).

There is an asset management policy for the management of all

assets within the SAS-SM environment.

Security rules are clearly defined and documented, either within

policies or as a stand-a-lone document.
There is an incident management policy and procedure in place,
applicable to both logical and physical incidents.

The procedures should include the notifications to stakeholders.

Incidents are recorded (e.g. on a ticketing system) and progressed

through the workflow.

There is a 3rd party management policy that includes the need for
external service provider contracts to include a liability clause that
defines responsibility and insurances to cover that liability.

There are standard SLAs/template contracts for customers, which

may include liability clause defining responsibility.

There is an information classification and handling policy in place.

There is an access management policy in place that is applicable to

both logical and physical access.
There are handling rules in place for the lifecycle of information,
proportionate to each level of classification.

There is an asset classification policy, either as part of the data

classification policy or a document in its own right.

There is a clear desk and clear screen policy in place.

All roles and responsibilities relating to the SAS-SM environment are

defined and clearly documented, either in job descriptions (where
security is a significant aspect of the role) or listed in a document
(where security is not a significant aspect).
There is a recruitment policy in place that define pre-employment
screening checks to be undertaken, including (subject to local laws -
details of laws preventing checks should be referenced):
- application form/CV
- formal interview
- validation of education and certifications
- validation of employment history and any gaps
- criminal background checks
- credit checks

There is a checklist/record of when checks were performed.

There is a procedure in place to ensure that re-validation checks are

performed (subject to local laws) on a regular basis (e.g. annually or
Bi-Annually (every two years)) for:
- criminal background
- credit checks

All individuals are required to sign a confidentiality agreement/NDA

as acceptance of security rules and behaviours, including:
employees, contractors, visitors, etc. This can be as part of the
contract of employment or a separate document.

All employees are required to sign a declaration as

acknowledgement of their understanding and acceptance of the
security policy, which is repeated each time the policy is updated
and communicated.

All new employees are subjected to induction training that includes

coverage of the security principles.

All employees are subjected to regular security awareness training

(e.g. annually). Employees involved in the SAS-SM environment are
also be subject to enhanced security training, specific to the
environment and controls.

There is a whistleblowing policy in place.

There is a disciplinary policy and procedure in place.

There is a termination of employment policy in place that defines
the actions to be taken in the event of a termination, including:
- revoking access rights
- recovery of equipment and devices

There is a checklist/record of when checks were performed.

The procedure includes the need to remind employees of their

obligations towards confidentiality and/or required to re-sign a
confidentiality agreement (e.g. as part of an exit interview).

There is a risk management policy in place supported by a

methodology, which includes a clear structure for risk identification,
assessment/evaluation, treatment, and management. Risks are
scored following an assessment of likelihood versus impact.

Regular risk assessments are performed on the datacentre/room

hosting the SAS-SM environment (initially as part of the
implementation to determine whether the controls in place are
sufficient to meet requirements and then at least annually or when
there is a change to the layout of the H.S.A.)

Risks are recorded and tracked in a risk register (there is a link to

section 1.2 regarding risk methodology) and used to drive a security
plan. Risk management is reported to the cross-functional security
forum (section 2.2.2)

There is a documented Security Plan that details zones of security

from public through to high security areas (H.S.A.) and the controls
required for each zone.

The security plan also includes procedures for response times and
escalation that demonstrate that the security controls are sufficient
to slowdown an attacker for longer than it would take to raise an
alarm and gain a response.
Physical controls should be in place, these typically include:
- the racks for the SM solution are physically segregated from other
racks by use of a cage (H.S.A.).
- entrance to the H.S.A. enforces one-by-one access and controls
ensure that at least two people must be present in the H.S.A.
- doors held open for longer than a specified period of time (e.g. 30
seconds) will generate an alarm.
- access control (badge access system) should enforce anti-pass-
back.
- the motion detection system should be configured to enforce
dual presence.
- all alarms should be locally audible and register in the security
control room.
- all access in/out of the H.S.A. is auditable through use of a badge
access control. Visitor access can be logged in a manual logbook that
records the in and out times and sufficient details of the individual.
- the HSA has sufficient CCTV coverage and motion detection.
- the racks are sufficiently secured with locks. The racks containing
the HSMs should be managed under dual control (e.g. two
padlocks).

There is a documented evacuation procedure that includes the

clearing of the H.S.A. in a secure manner. This should be subject to
testing on a regular basis.

Badge access system logs all access and logs are retained for a
sufficient period of time to support investigation in the event of an
incident. Typically, this is considered to be 1 year.

CCTV image recordings meet the guidelines of 6fps and retention of

recordings for 90 days (where permitted by local laws - if this is not
permitted then you will need to provide details of the law).

Screenshots of expected CCTV images are taken and used as a

baseline, which is checked periodically to confirm the actual CCTV
image and quality is as per the baseline.

CCTV and badge access system date and time are synchronised.
CCTV and badge access systems are restricted to only security staff.

There is documented floor plan, which is maintained up-to-date that

details the controls in place protected the H.S.A.

There are regular checks to confirm that the floor plan controls are a
true reflection of the actual controls.

There is an access management policy (should already have been

provided as part of requirement 3.2.1) that defines access and
approvals to secure areas by:
- employees,
- visitors,
- contractors, and
- security personnel.

The policy should also define how goods are brought into/out of the
HSA (e.g. by use of a good tool trap or by disabling door controls. If
doors are disabled then this should be approved and additional
temporary controls applied).

The policy is enforced by an access control system (e.g. badge

access system), employees are required to wear id cards at all times.
The ability to amend access rights within the system is restricted to
limited number of staff (e.g. physical security manager).

All changes made to access rights within the badge access system is
auditable.

There is a procedure for managing physical keys (e.g. keys for racks,
safes, etc.) that ensures that they are securely held under dual
control and only issued to an individual upon approval. When
issued, there should be a logbook maintained detailing when the
key was taken and returned.

The badge access system generates logs of permissions and activity

that are reviewed on a regular basis for any suspicious activity,
which is supported by reviews of corresponding CCTV recordings to
confirm the BAS log activity.

There is a documented operational security procedures manual that

is provided to all security personnel and includes:
- security operations of the site, including incident management.
- handling of sensitive assets (bringing assets in/out of the HSA)
- access control system and badge management
- dealing with employees, visitors, contractors.
- physical key management
- alarm system
- CCTV system
- Emergency evacuation
- internal checks and audits

The manual should be reviewed annually and updated when

required.

All security personnel are subject to vetting (as per requirement

4.2.1) on a regular basis.

All security personnel are trained on a regular basis (e.g. annually)

with regard to their duties (e.g. the content of the operational
security manual).
There is an established programme for internal checks and audits,
which list all of the checks/audits to be performed, together with
the frequency (e.g. daily, weekly, fortnightly, monthly, quarterly,
semi-annual, annual, bi-annual (two years)). If using a 3 lines of
defence model, the line performing the check is listed in the
programme.

For each check/audit activity, the following is documented:

- purpose,
- scope (including period covered and population)
- objective,
- methodology for testing
- details of testing undertaken
- findings / observations
- observations
- conclusion
The outcome of checks/audits are reported promptly and actions to
address recommendations tracked.

The checks are performed by appropriately trained personnel,

whom are independent of the team operating the control.

There is an information classification and handling policy that

defines the levels of classification. There are handling rules in place
for the lifecycle of information, proportionate to each level of
classification.

The classification levels are aligned/mapped to those of the GSMA

FS.08 Annex A (e.g. the class 1 and class 2 GSMA classifications to
the classification levels in use).

A encryption key lifecycle is defined for each key type, which

includes the classification level.

Certificate lifecycle is defined for each certificate type, which

includes the classification level.

A Key Manager and Key Manager Backup have been formally

appointed by an appropriate officer (e.g. CISO).

You have evidence of these formal appointments (e.g. an

appointment letters).

The Key Manager and Key Manager Backup have formally accepted
their responsibilities.

There is a Key Management Organisational Chart is defined that

shows the role, name, job title, reporting manger. Each group of
custodians should not report to the same line manager.
All key management personnel roles and responsibilities have been
defined and documented. This can be as a part of key management
policy or a standalone document.

Each individual is formally appointed and has signed a declaration

confirming their acceptance of the additional responsivities. This
declaration should be retained either in the employee's personnel
file or by the key manager. The appointment of key management
personnel (excluding key manager and backup) should be repeated
annually following their re-vetting.

Each Individual has been vetted by the key manager, in association

with HR and CISO, as to their suitability. For example, they have a
good employment record with no disciplinary records, financial or
criminal record check anomalies. This vetting should be repeated on
an annual basis.

Only appropriately trained individuals perform key management

activities. Each individual has been subjected to regular key
management training. Training should be performed at least
annually. A record should be maintained of attendance of the
training. Training should include performing mock ceremonies.

There is a key management policy and procedure in place that

describes how dual control is applied throughout all key
management activities. This includes the receiving, handling
distributing key components; physical access to the room, racks and
safes; and logical access to the KMS and HSMs.

Physical keys used for safes, racks, etc. not assigned to individuals
should be held centrally (unusually within a key safe).

Physical access in the H.S.A. requires a minimum of two persons

present (dual presence). If a single person is present for longer than
1 minute, an alarm is triggered.
Physical access to the racks requires two individuals (e.g. the racks
are managed under dual control).

Physical access to the safes requires two individuals to open them.

One individual is the key custodian (or backups) to whom the safe
belongs and the other individual is the key manager (or backup).

Logical access to systems used for key management require two

individuals, i.e. the password is managed under split knowledge
(both parts of the password should be managed in line with the
password policy (10.3.3))

A encryption key lifecycle is defined for each key type, which

includes the classification level.

Certificate lifecycle is defined for each certificate type, which

includes the classification level.

A key and certificate inventory is maintained that lists all of the keys
and certificates in use for the SAS-SM environment.

A procedure should be in place to manage the expiry of keys and

certificates.

A encryption key lifecycle is defined for each key type, which

includes the classification level.

Key management is governed by following the principles of split

knowledge and dual control (as described in previous requirements
above). These principles are expected to be demonstrated
throughout all key management activities.
Key Management procedures are documented for all key
management activities including:
- Roles and Responsibilities
- Succession Planning
- HSM commissioning
- HSM initialisation
- HSM decommissioning
- Key Lifecycle - Generation
- Key Lifecycle - Exchange and Storage
- Key Lifecycle - Backup (if applicable)
- Key Lifecycle - Destruction
- Private Keys
- Key Compromise

Certificate management procedures are documented for all

certificate management activities including:
- certificate requests
- certificate loading
- certificate revocation
- certificate deletion
- certificate compromise

There is a hardware inventory in place (10.5.1) that includes details

of all HSMs in use.
For each HSM, evidence is available to confirm it is FIPS 140-2 level
3 certified.

All key management activities have a manual record completed,

which provides sufficient detail to record the activities under, by
whom and when.

Each HSM maintains an audit log.

Either as a separate document or as part of the ceremony record, a

pre and post ceremony checklist should be completed that details
the inspection performed to ensure there is no evidence of
tampering, powering up, powering down, and returning the KMS to
its original state (e.g. removing monitors, etc.), closing the rack, etc.

Key Management safe access logs and safe inventories are

maintained that detail every time a key management safe is
opened, the purpose, and the content of the safe. Both should be
managed under dual control and subject to regular inspection (e.g.
quarterly).
Certificate management procedures are documented for all
certificate management activities including:
- certificate requests
- certificate loading
- certificate revocation
- certificate deletion
- certificate compromise

The GSMA PKI certificates in use are signed by the authorised CA.

Certificate management procedures are documented and include

the restrictions over PKI certificate private keys used for signing and
in accordance with the certificate policy (SGP.14).

Certificate management procedures are documented and include

the restrictions over PKI certificate key pairs and notification to the
GSMA's email address.

Certificate management procedures are documented and include

the restrictions over PKI certificate key pairs and notification to the
GSMA's email address.

There is a documented solution architecture, which includes

functionality. Within this document, all of the data and assets are
listed together with the various ES channels.

For each ES, there is a description of how the data is secured. In

addition, the document includes how the data is secured at rest
(e.g. field encryption and database encryption). This should be
aligned to the data classification and handling policy and procedures
(section 3).
All connections between secure networks (SM solutions) and
unknown networks (everything else) is via a system within the DMZ.
There are controls to prevent unauthorised access to the SM
solution network. Where virtualisation is implemented, there is a
physical host for each zone (i.e. the virtualisation does not span
multiple zones).

There is a roles and responsibilities matrix defined (requirement

2.2.2) that ensures that access to sensitive data is only where
absolutely necessary.

There is a segregation in administrator duties (e.g. network, system,

and database). If the same individuals have administration access to
all levels then you are expected to demonstrate that there are
compensating controls such as logging and monitoring of all
activities.

There is an information classification and handling policy that

defines the levels of classification (requirement 3.1.1).

There is a documented solution architecture, which includes how

the data is secured at rest (e.g. field encryption and database
encryption). Covered as part of requirement 7.1.1.

There is a data retention policy in place, which defines the retention

periods for all types of data, which is in accordance with contractual
and legislative requirements.

The policy also describes how data should be removed/deleted

securely, in accordance with the classification and handling policy.
There is an event management policy and procedure in place, which
defines the audit and monitoring for the network devices and
systems and applications.

All activity is subject to logging and monitoring that captures:

- the identity of the user performing the action?
- the date and time of the action?
- the nature of the action?
- the outcome of the action (i.e. success/failure) including
attempts to exceed privileges?

Audit trails are maintained for:

- applications that handle the data processing activities
- Operating Systems (OS)
- Databases/database tools

The integrity of the audit trail is maintained. This can include

ensuring that administrators are unable to access logs and/or
utilisation of log repositories that receive logs in real-time.
Administrators do not have access to the repositories.

There is a roles and responsibilities matrix in place, which

demonstrates that operational administrators are unable to have
write access to the logs.

Logs are subjected to regular monitoring (covered in section 10.6.1)

with automated alerting of malicious events (this should feed into
incident management (section 2.3.1).
Logs exist that cover the entire lifecycle of the asset and user access.
This should be aligned to data retention and deletion procedures
(requirement 7.2.3) whereby data is retained for a sufficient period
to identify and investigate incidents and deleted securely.

Comment: There is overlap here between audit trail integrity

(section 7.4.1) and retention (section 7.2.3).

The integrity of the audit trail is maintained. This can include

ensuring that administrators are unable to access logs and/or
utilisation of log repositories that receive logs in real-time.
Administrators do not have access to the repositories.

There is a roles and responsibilities matrix in place, which

demonstrates that operational administrators are unable to have
write access to the logs.

Log data does not include details of the sensitive data and only
sufficient details to enable further investigation.
Where sensitive data includes authorised and/or duplicate
production (e.g. manual generation or manipulation of production
data or changes to the status of production data), this is fully
auditable with sufficient evidences retained and there are adequate
controls in place such as '4-eyes' whereby all actions are validated
by a second person.

The solution architecture and functionality document includes a

description of how duplicate production is prevented. This should
also include whether it is possible to reuse a profile after it has been
deleted from the end-user's device or whether it is deleted from the
database.
There is a documented solution architecture, which includes
functionality. Within this document, all of the data and assets are
listed together with the various ES channels.

For each ES, there is a description of how the data is secured. In

addition, the document includes how the data is secured at rest
(e.g. field encryption and database encryption). This should be
aligned to the data classification and handling policy and procedures
(section 3).

There is a use case specification document that explains how the

interfaces work and the testing to demonstrate this for ordering a
profile and its lifecycle.

There is an established programme for internal checks and audits,

which list all of the checks/audits to be performed, together with
the frequency (e.g. daily, weekly, fortnightly, monthly, quarterly,
semi-annual, annual, bi-annual (two years)). If using a 3 lines of
defence model, the line performing the check is listed in the
programme.

For each check/audit activity, the following is documented:

- purpose,
- scope (including period covered and population)
- objective,
- methodology for testing
- details of testing undertaken
- findings / observations
- observations
- conclusion
- recommendations for improvement

The outcome of checks/audits are reported promptly and actions to

address recommendations tracked.

The checks are performed by appropriately trained personnel,

whom are independent of the team operating the control.
There is a documented solution architecture, which includes
functionality. Within this document, all of the data and assets are
listed together with the various ES channels as per the SGP
documents.

For each ES, there is a description of how the data is secured. In

addition, the document includes how the data is secured at rest
(e.g. field encryption and database encryption). This should be
aligned to the data classification and handling policy and procedures
(section 3).

There is an information classification and handling policy that

defines the levels of classification. There are handling rules in place
for the lifecycle of information, proportionate to each level of
classification.

There is a documented solution architecture, which includes

functionality. Within this document, all of the data and assets are
listed together with the various ES channels as per the SGP
documents and classification and handling scheme.

The solution architecture and functionality documentation includes

details of data segregation between customers.

There is a use case specification document that explains how

customer data is protected and cannot be accessed by other
customers.

The solution architecture and functionality documentation includes

details how multi-tenancy is achieved. This should be supported by
the network architecture (10.4.1) and asset inventory (10.5.1 (i)).

There is a use case specification document that explains how

customer data is protected and cannot be accessed by other
customers.
All network configurations are clearly documented (e.g. there is a
network diagram). There should also be a diagram that shows the
secure interfaces over the network to demonstrate the assets used
at each stage of the SM solution. This should also be reflected in
the solution architecture.

The network architecture diagram should include details of the

communication channels and secure interfaces. Solutions for
ensuring that authentication is appropriate is through the use of
certificate, VPN with HTTPS, encryption keys. You will be expected
to have included the mechanisms as part of the documentation.

There is a use case specification document that explains how

entities authentication is verified.

There is an event management policy and procedure in place, which

defines the audit and monitoring for the network devices and
systems and applications.

All activity is subject to logging and monitoring that captures:

- the identity of the user performing the action?
- the date and time of the action?
- the nature of the action?
- the outcome of the action (i.e. success/failure) including
attempts to exceed privileges?

Audit trails are maintained for:

- applications that handle the data processing activities
- Operating Systems (OS)
- Databases/database tools

The integrity of the audit trail is maintained. This can include

ensuring that administrators are unable to access logs and/or
utilisation of log repositories that receive logs in real-time.
Administrators do not have access to the repositories.

There is a roles and responsibilities matrix in place, which

demonstrates that operational administrators are unable to have
write access to the logs.
Logs are subjected to regular monitoring (covered in section 10.6.1)
with automated alerting of malicious events (this should feed into
incident management (section 2.3.1).

Logs exist that cover the entire lifecycle of the asset and user access.
This should be aligned to data retention and deletion procedures
(requirement 7.2.3) whereby data is retained for a sufficient period
to identify and investigate incidents and deleted securely.

[this is a repeat of section 7.4 and 8.3.1, above]

There is an up-to-date IT security policy that supports the overall

information security policy (defined within section 1) and forms part
of the policy framework.

All roles and responsibilities relating to the SAS-SM environment are

defined and clearly documented, either in job descriptions (where
security is a significant aspect of the role) or listed in a document
(where security is not a significant aspect).

The roles and responsibilities matrix demonstrates there is a

segregation in administrator duties (e.g. network, system, and
database). If the same individuals have administration access to all
levels then there are appropriate controls in place such as logging
and monitoring of all activities.
There is an access management policy (should already have been
provided as part of requirement 3.2.1) that defines access and
approvals to secure areas by:
- employees,
- visitors,
- contractors, and
- security personnel.

The policy is enforced by an access control system (e.g. badge

access system), employees are required to wear id cards at all times.

There is an access management policy in place that is applicable to

both logical and physical access (these can be two separate
policies), which includes the principles of 'least privilege' and 'need
to know'.

The policy is supported by procedures that define the process for

creating, modifying, and deleting access rights. All processes should
include an approval mechanism (e.g. tracked through a ticketing
system with the approval).

The policy and procedures are applicable to all types of accounts:

administrator, user (if applicable), machine/service, local and
domain accounts.

There is a list of approved users (independent of the systems

themselves). This list should be maintained up to date and used to
review the list of actual accounts to confirm all accounts on the
network and system have been authorised. Any anomalies identified
should generate an incident that are tracked through the incident
management process.
There is a password policy that is defined either as part of the IT
Security policy or as a standalone policy. The policy clearly states
that it is applicable to all: users, machine/service accounts, network
devices, systems, and applications. If there are any accounts that do
not meet the policy requirements (see below) then these should be
listed as exceptions.

The policy specifies:

- password length
- complexity
- maximum age
- minimum age
- password history

In addition: account lockout and screen lock should be specified.

The policy includes the need for additional controls for systems that
cannot enforce the password policy through configuration settings.

The policy states that all generic accounts (e.g. 'admin') that are not
identifiable to an individual should be managed under dual control
with the password split between two individuals. Both parts of the
password must meet the above requirements (e.g. both parts of the
password meet the minimum length specified).
The access management policy/procedures define the process for
remote access, including the authentication methods.

There should not be any direct access from outside the trusted
zone. Remote access should make use of jump hosts in the DMZ,
which are used to connect to the trusted zone. There should not be
any remote access to the HSMs.

Where remote access takes place from a dedicated physical

location, this must have the same level of control defined within the
layers of physical security (section 5).

Remote access should be limited to a small number of users on

dedicated machines (e.g. certificate based authentication and client
software on the device). It should not be possible to use a device
that is not owned by the company (e.g. an employee's personal
device).

The policy/procedure documents:

- name of individual with remote access
- purpose of access
- location(s) from where access is permitted
- authorisation for access

The list of users with remote access is reviewed regularly to confirm

that remote access is required.

The remote access account lockout is more restrictive than for

normal account access (e.g. 3 failed login attempts).
All network configurations are clearly documented (e.g. there is a
network diagram). There should also be a diagram that shows the
secure interfaces over the network to demonstrate the assets used
at each stage of the SM solution.

The network topology supports a security in depth model.

All connections between secure networks (SM solutions) and

unknown networks (everything else) is via a system within the DMZ.
There are controls to prevent unauthorised access to the SM
solution network. Where virtualisation is implemented, there is a
physical host for each zone (i.e. the virtualisation does not span
multiple zones).

There is a firewall policy, which is supported by a build (hardening

standard) for each model of firewall. Any configurations above this
are subject to change control. You have all firewall configurations
documented.

There is an approved firewall ruleset, which is configured to only

provide the minimum access required, restricting IP addresses,
services, and ports and include a deny all rule (catch all rule).

There is a change management policy and procedure in place. All

firewall changes follow the change management process.
There is an intrusion detection system in place that monitors
network traffic within the trusted zone and generates immediate
alerts.

There is a programme of penetration testing, which specifies the

frequency of penetration testing (e.g. twice a year and after a major
change) and the scope, including: external and internal networks.

The results of testing is recorded and actions taken tracked.

Expected resolution times per severity level should be specified.

The network architecture has been designed to account for

expected availability (linking to the recovery point objective within
the business continuity plan). This may include clusters (active |
active; active | passive) with redundancy.

There are appropriate controls to detect and prevent attacks that

would impact on the availability (such as denial of service). This
should be linked to risk registers, intrusion detection, and business
continuity. It will only need to be demonstrated that the risk has
been considered and appropriate measures have been taken.

There is a procurement procedure, which includes the need for

security requirements from the outset and these are factored into
the procurement of assets.

You have an asset inventory that includes all hardware and

software.

The inventory should be maintained up to date and subject to

regular checks to actual assets.
There is a patch management policy, either as part of the IT security
policy or as a standalone document. It is supported by patch
management procedures for:
- network devices
- operating systems
- applications/components utilised within the SM environment

The policy should ensure that all systems are maintained with the
latest vendor-supplied security patches once they pass testing.

The policy should specify how to handle out of support (end of life)
systems that cannot be replaced and require additional controls.

There is a build/hardening policy that is applicable to all systems

and is supported by procedures for each type of device, which are
based on vendor recommendations and/or industry good practices
(e.g. CIS, NIST, SANS).

The actual configuration of systems is checked against the baseline

standard on a regular basis. This can either be through event log
alerts or manual inspection. Any anomalies generate an incident.

There is a change management policy and procedure that is

applicable for all systems and requires that there is a formal process
to only permit authorised changes and detect unauthorised changes
(these would generate an incident).
There is a vulnerability management policy in place, which is either
part of the IT Security policy or a document in its own right. This can
also be included as part of the patch management policy.

The policy/procedures should include the need to subscribe to

vendors, security websites, newsfeeds, etc. to identify all potential
vulnerabilities and assess the impact on the network.

The policy is supported by procedures that define a programme for

vulnerability scanning of the external and internal networks and the
frequency of scans.

The results of testing is recorded and actions taken tracked.

Expected resolution times per severity level should be specified.

There is a malware prevention strategy that:

- defines a malware perimeter for the site
- emphasise prevention as the primary control
- emphasise that detection controls are also important

Anti-virus software is installed on all systems that can support it and

is configured to look for signatures daily, actively scan, and log
events.

There is a defined procedure for handling viruses, which include

raising an incident.
There is a policy for session timeouts of unattended terminals (this
can be covered in the password policy) that includes: network
devices, systems, end user pcs, and remote access.

There is a decommissioning/decertification procedures in place as

part of the asset management policy that ensures there is an asset
lifecycle management in place and secure destruction of assets.

There is a backup and retention policy defined. The backup policy

should be part of the business continuity planning and aligned to
customer expectations and the retention policy should be part of
the data classification and handling policy.

Backup and retention should include configurations, data and audit

logs.

There is an event management policy and procedure in place, which

defines the audit and monitoring for the network devices and
systems. Logging must be enabled for applications (linked to section
7.4).
There are regular checks to confirm that all network devices and
systems are generating and forwarding logs for interrogation.

Logs are subjected to regular review and any abnormal events

generate an incident and are investigated.

There is a 3rd party management policy that includes the need for
external service provider to be monitored through SLAs and be
subject to monitoring.

External providers should sign NDAs and the contract should ensure
that they will adhere to your policies and procedures.

There is am established programme for internal checks and audits,

which list all of the checks/audits to be performed, together with
the frequency (e.g. daily, weekly, fortnightly, monthly, quarterly,
semi-annual, annual, bi-annual (two years)). If using a 3 lines of
defence model, the line performing the check is listed in the
programme.

For each check/audit activity, the following is documented:

- purpose,
- scope (including period covered and population)
- objective,
- methodology for testing
- details of testing undertaken
- findings / observations
- observations
- conclusion
- recommendations for improvement
The outcome of checks/audits are reported promptly and actions to
address recommendations tracked.

The checks are performed by appropriately trained personnel,

whom are independent of the team operating the control.

There is a secure software development lifecycle (SSDLC)

methodology in place, which has been adopted for the development
of the SM solution.

The SSLDC includes security is defined at the earliest point

(requirements) and tracked through all phases. In addition, the
solution is subject to application penetration testing.
uditors Will Assess Compliance

Detailed Testing

Review the Information Security Policy and confirm that it is

endorsed by senior management and includes a clear statement on
the overall security principles and management intent.

Review sample of policies to confirm that they have been reviewed

on a regular basis and updated when required.

Interview a sample of staff and confirm they have access to the

policies.

Review acknowledgements for all employees involved in the SAS-SM

environment.
Review the risk management policy and methodology and confirm it
includes a clear structure for risk identification,
assessment/evaluation, treatment, and management.

Risks are scored following an assessment of likelihood versus

impact.

Review a sample of risk assessments to confirm they occur regularly.

Trace a sample of risks from the assessments into the risk register to
confirm and a sample of risks from the risk register back to the risk
assessments.

For a sample of risks confirm that the scoring is in line with

methodology.
For a sample of risks that require action, confirm they have an
owner, and actions are being tracked.
Review a sample of CFSF minutes, and confirm that the risk
management is a standing agenda item and risk actions are being
monitored.

If a stand-alone document, trace a sample of actions from the

strategy to the risk register and a sample of strategic risks (long-
term actions) from the risk register to the security strategy.
Review a sample of CFSF minutes, and confirm that the strategy is a
standing agenda item, which is subject to monitoring.

Review a sample of customer contracts/SLAs for availability

requirements and confirm they are reflected in the BCP.

Review a sample of business impact assessments and confirm they

are undertaken regularly.
Review the BCP and confirm it reflects the outcome of the most
recent Business Impact Assessment.

Review a sample of tests and confirm that they have been

successfully completed. Where tests were not completed as per the
plan, confirm that the lessons learnt have been captured and the
plans updated to reflect corrective actions.

For a sample of checks, confirm that they have been undertaken in

accordance with the intended frequency.

Review a sample of checks for all areas of control and confirm that
they have been fully documented and undertaken in line with the
testing methodology.

Performed at the end of the audit: for any NCs and C- findings,
ascertain if they were covered in the scope of an internal
check/audit and identified.

Review a sample of CFSF minutes, and confirm that internal checks

and audits is a standing agenda item and progress on actions are
monitored.

Interview personnel / review HR records and confirm individuals are

appropriately trained and competent to perform their role.
Review the Organisational structure and confirm it includes all areas
of the business involved with the solution and environment,
including a high-level (e.g. company name) of external providers.

Confirm that the organisational structure includes the names and

positions of employees involved in the SAS-SM environment.

Review membership of the forum and cross-reference to the

organisational chart to confirm all areas are represented.

For a sample of meetings, review evidence that security-related

matters are reported, together with decisions made and tracking of
actions.

Review the appointment letter and job description for the individual
with overall responsibility for the SAS-SM security controls.

Confirm that SAS-SM is stated within the area of responsibility.

For a sample of roles, cross-reference to the organisational structure

for completeness.

For a sample of individuals, confirm that they have accepted their

responsibilities. Usually performed as part of section 4.

Review the asset management policy and confirm it covers the

whole of the asset lifecycle for all assets relating to the SAS-SM
environment.

The policy should include defining assets in an inventory and

assigning responsibilities and accountability for each asset.

Review a sample of policies and confirm they include security rules.

Review the incident management policy and procedure and confirm
that it is applicable to both logical and physical incidents.

The policy should also define the steps to be taken to: identify, log,
evaluate, triage, investigate, resolve and report incidents and
improve control weaknesses.

The policy/procedure should also define how evidences are to be

handled meeting any forensic readiness and chain of custody
requirements by law enforcement agencies.

Confirm that the policy includes notification to internal and external

stakeholders (e.g. customers, external providers, law enforcement
agencies) and the point at which they are contacted.

Review all of the incidents relating to the SAS-SM environment. For

a sample, review the steps taken and reporting.

Ascertain all external service providers where there is a dependency

on security. For a sample, review the contracts and confirm liability
is defined. Confirm that copies of insurance certificates have been
obtained.

Ascertain the number of customers where contracts have been

signed. Review a sample of contracts and ascertain if liability has
been defined.

Ascertain whether the vendor has calculated the total value of

liability that would be payable to customers, and has appropriate
insurance in place to mitigate this and/or appropriate levels of
control. This should also be listed in the risk register (1.2.1).

Review the information classification policy and confirm that defines

the levels of classification in place for all types of data across the
organisation.

The classification levels are aligned/mapped to those of the GSMA

FS.08 Annex A (e.g. the class 1 and class 2 GSMA classifications to
the classification levels in use).

Review the access management policy and confirm it covers both

logical and physical access (these can be two separate policies).

Confirm that the policy includes the principles of 'least privilege' and
'need to know'.
Review the classification and handling policy and confirm that, for
each classification level, the handling controls have been defined for
all aspects of the information lifecycle, including (but not limited to):
- creation/first point of receipt;
- communicated:
- written
- verbally spoken
- electronically communicated (internally and externally)
- removable media (e.g. USB stick, memory card, etc.)
- stored (physically and electronically)
- destroyed

Review the asset classification policy and confirm it defines the

controls (both logical and physical) in place for the lifecycle of the
assets.

Ascertain is there is also a site classification policy, which specifies

the physical controls required for hosting assets (this is covered in
detail within section 5 for layers of physical security).

Review the clear desk policy and confirm that it is aligned to the
classification and handling policy, whereby confidential documents
and material should be stored securely and not left at workstations.

Review the clear screen policy and confirm that it is aligned to the
session timeout requirements (requirement 10.5.1 (vii)) and
addresses issues such as shoulder-surfing in public places and
restricting CCTV recording of screens that are used for sensitive
processes (e.g. key management).

For a sample of individuals, confirm that they have accepted their

responsibilities.
For a sample of employees involved in the SAS-SM environment
(cross-reference to 2.1.1 and 2.2.2), confirm that a personnel record
exists covering the recruitment screening checks

For a sample of employees involved in the SAS-SM environment,

confirm that criminal background and credit checks are performed
regularly.

For a sample of employees involved in the SAS-SM environment

(cross-reference to 2.1.1 and 2.2.2), confirm that confidentiality
agreements/NDAs have been signed.

Review acknowledgements for all employees involved in the SAS-SM

environment.

For a sample of new starters, confirm that they have received

instruction training that includes security awareness / the security
principles.

Review the security awareness training and enhanced security

training course material and confirm it reflects the security policies,
rules, and standards.

For a sample of employees, confirm that they have received the

security awareness training on a regular basis (e.g. annually).

For a sample of employees involved in the SAS-SM environment,

confirm that they have received the enhanced security training.

Review the whistleblowing policy and confirm that there is a process

that enables employees to make confidential reports of security
policy breaches and should include escalation in the event that the
employee is not satisfied with the outcome (e.g. an ombudsman).

Review the disciplinary policy and procedure and confirm that they
define the levels of disciplinary action based on levels of severity,
including dismissal.
For a sample of terminations of employees who were involved in
the SAS-SM environment, confirm that a personnel record exists
covering the termination checks.

Confirm the procedure includes the handling of standard

terminations and immediate terminations of employment due to
gross negligence.

For a sample of terminations of employees who were involved in

the SAS-SM environment, confirm that there is evidence of
employees re-signing the confidentiality agreement.

Review the risk management policy and methodology and confirm it

includes a clear structure for risk identification,
assessment/evaluation, treatment, and management.

Risks are scored following an assessment of likelihood versus

impact.

Review the risk assessment performed for the implementation of

the H.S.A. to confirm it was undertaken in accordance with
methodology.

Review change management records for changes to the layout of

the H.S.A. Select a sample of changes and confirm a risk assessment
was undertaken.

Trace a sample of risks from the assessments into the risk register to
confirm and a sample of risks from the risk register back to the risk
assessments.

For a sample of risks confirm that the scoring is in line with

methodology.
For a sample of risks that require action, confirm they have an
owner, and actions are being tracked.
Review a sample of CFSF minutes, and confirm that the risk
management is a standing agenda item and risk actions are being
monitored.

Review the security plan and confirm that layers of security (zones)
have been defined together with the controls required to access
each zone and within the zone.

Review the security plan and confirm it includes attack and response
times for each layer being breached.

Verify the physical layout of the site and the controls in place to
confirm that threats would be detected and the responses are
reasonable.
Physically verify the controls that are expected to be in place are
actually in place and appropriate.

Review the evacuation procedure and results of testing performed.

Review the security plan (or security policy) to confirm that BAS logs
are to be retained for a minimum of 1 year. (NB the period of
retention should be reflected within the incident response policy
and procedure, whereby alerts are generated and investigated
within the timeframe logs and other evidence is available). Review
the BAS system and confirm logs are retained for the required
period.

Review the CCTV management system to confirm the configuration

of recordings and retention. (NB the period of retention should be
reflected within the incident response policy and procedure,
whereby alerts are generated and investigated within the timeframe
logs and other evidence is available). Review the BAS system and
confirm logs are retained for the required period.

Physically verify the baseline screenshots to live images to confirm

they are aligned.

Review the control to synchronise the CCTV and BAS systems.

Physically inspect the two systems to confirm that they are
synchronised.
Review the user accounts for the two systems and confirm that they
are restricted to a limited number of employees. Cross-reference
the employees to the roles and responsibilities defined in
requirement 2.2.2.

Verify the floor plan controls against the actual controls in place to
confirm that the plan is up-to-date and a true reflection of the
actual controls.

Review evidences (such as internal checks and audit test results) to

confirm that the floor plan is checked periodically to actual controls.

Review the policy and confirm that it includes details of how

requests are made and approved.

Obtain a list of individuals with permanent physical access. For a

sample, confirm that there is a ticketed request, which has been
appropriately approved.

Obtain an activity report from the BAS system. Identify individuals

whom do not have permanent access, and for a sample, confirm
that there is a ticket request, which has been appropriately
approved. Review the account for these individuals within the BAS
and confirm that access is no longer valid.

Obtain a list of contractors and security personnel with physical

access, if handled differently to permanent/temporary access. For a
sample, confirm that there is a ticketed request, which has been
appropriately approved.

Review the policy for details of how goods are brought into/out of
the H.S.A. Review the ticketing systems for such requests. If they are
within the period of CCTV recordings, review the corresponding
CCTV recordings to confirm the process was followed.

During the audit, confirm that employees are wearing their ID

badges at all times.
Inspect the BAS system and confirm the access rights for each user
account to verify that only a limited number of staff can amend the
access rights.

Ask two individuals (one with permission and one without) to

demonstrate that the permissions are accurate. Typically, those
without permission will have a different layout.

Review the procedure for handling physical keys.

Confirm that keys are held under dual control.

Review the logbook to confirm that the issue and return of keys is
in accordance with the procedure.

Confirm that reviews of BAS are included in the internal checks and
audit programme, to review:
- individuals with access (e.g. quarterly)
- activity for each badge reader (e.g. weekly or monthly)

For a sample of activity, review the corresponding CCTV footage to

confirm that badge activity recorded is a true representation of
actual events.

Review the security procedures manual and confirm it includes all

expected aspects, such as those listed.

Confirm that the manual is subjected to regular review (e.g.

annually) and updated when required.

Obtain a list of security personnel. For a sample, confirm that

individuals have been subjected to similar levels of vetting as
operational employees.

Review the security guard training course material and confirm it

reflects the security policies of the vendor and the operational
security procedures manual.
For a sample of checks, confirm that they have been undertaken in
accordance with the intended frequency.

Review a sample of checks for all areas of control and confirm that
they have been fully documented and undertaken in line with the
testing methodology.

Performed at the end of the audit: for any NCs and C- findings,
ascertain if they were covered in the scope of an internal
check/audit and identified.

Review a sample of CFSF minutes, and confirm that internal checks

and audits is a standing agenda item and progress on actions are
monitored.

Interview personnel / review HR records and confirm individuals are

appropriately trained and competent to perform their role.

Review the classification level assigned to encryption key and

certificate types and confirm they are aligned to the GSMA FS.08
Annex A class 1 and class 2 types. Cross-reference the handling
guide for the classification level and confirm it is appropriate.

Review the appointment letters for the Key Manager and Key
Manager Backup

Confirm that the responsibilities for the Key Manager and Key
Manager Backup are documented and both have formally accepted
these responsibilities.

Review the organisational chart for key management personnel.

Review each custodian group to confirm that there is a segregation
of reporting lines.
Confirm that roles and responsibilities for all personnel involved in
key management activities are documented. Cross reference the
roles to the organisational chart.

Review evidences to confirm that each individual has been formally

appointed and has accepted their responsibilities.

Review evidence of the latest vetting undertaken for each

individual.

Review the key management training course material and confirm it

reflects the key management policies and procedures (requirement
6.4.1). Review evidence of attendance by those participating in the
training and cross-reference to the key management organisational
chart.

Observe a mock key ceremony to confirm that individuals involved

are competent to perform their duties.
Review the key management policy and procedures and confirm
that it details how dual control is applied throughout all aspects of
key management (as detailed below)

The physical location of the key store is covered as part of

requirement 5.3.1. In addition, review the list of authorised
personnel to have physical keys and confirm only key management
personnel (cross-reference to the key management organisational
chart) are authorised to access the keys.

Review the physical key logbook for instances where rack keys have
been taken and confirm that the dates and times correspond to key
ceremonies.

This is covered as part of 5.2.1 (repeated here)

Physically verify the controls that are expected to be in place are

actually in place and appropriate.
Physically inspect the racks and confirm that the racks are not
accessible under single control, this includes inspecting:
- the racks adjacent to the HSM rack to confirm access cannot be
gained from there; and
- the side panels of the racks
- the keys used to secure the racks against all other rack keys in the
key store (looking for duplicates that would result in single access)

Physically confirm that each safe requires two individuals to open it,
such as:
- two keys
- one key and pin code
- two parts of a pin code

Observe the login process during the mock key ceremony to confirm
that passwords are managed under split knowledge and both parts
of the password meet the password policy.

Review the lifecycles for keys and certificates and confirm the
technical specifications are appropriate for the purpose of each
key/certificate.

For a sample of keys and certificates held in the HSMs, confirm that
the technical specifications are correct per lifecycles and cross-
reference to the inventories and ceremony forms.

Review the lifecycle of keys and certificates to confirm that the

expiry length is appropriate.

Review the process for destroying keys when they expire and
replacing them.

For a sample of keys and certificates held in the HSMs, confirm that
the expiry dates are correct per lifecycles and cross-reference to the
inventories and ceremony forms.

Review the lifecycles for keys and certificates and confirm the
technical specifications are appropriate for the purpose of each
key/certificate.

Observe a mock key ceremony to confirm that the principles of split

knowledge and dual control are applied throughout.
Review the key management procedures and confirm they cover all
aspects of key management.

For a sample of key ceremonies performed (6.5.1), confirm that the

ceremonies are in accordance with procedures.

Observe a mock key ceremony to confirm that it is undertaken in

accordance with the procedures.

Review the certificate management procedures and confirm they

cover all aspects of certificate management.

For a sample of certificates in use, confirm that there is an audit trail

(6.5.1) and procedures were followed.

Physically inspect each HSM and confirm the serial number agrees
to the inventory record.
Physically inspect each HSM to confirm that they are configured to
be running in FIPS/secure mode in accordance with the FIPS
certification.

Review the key inventory and, for a sample of keys, check that the
details recorded agree to the corresponding ceremony form and
HSM audit log. For a sample of keys in the HSM, trace through to
the key ceremony form and inventory.

For a sample of key ceremonies, confirm that pre- and post-

ceremony checks are recorded.

Observe a mock key ceremony to confirm that pre- and post-checks

are performed.

For each safe in use, confirm that logbooks are maintained and
physically verify the content of each safe to the inventory record.

For each inventory logbook, review for evidence of regular

inspection.
Review the certificate management procedures and confirm they
cover all aspects of certificate management.

For a sample of certificates in use, confirm that there is an audit trail

(6.5.1) and procedures were followed.

Confirm the GSMA PKI certificates in use and confirm they are
signed by the authorised CA.
Review the certificate management procedures and confirm they
include clear rules for certificates used for signing.

For a sample of private keys used for signing, confirm that they are
in accordance with the procedures and certificate policy.

Review the certificate management procedures and confirm they

include clear rules for transfer and installation, which includes
notification to the GSMA compliance email address.

For a sample of certificates, confirm that they are transferred and

installed in accordance with procedures and the GSMA has been
informed of the certificates.

Review the certificate management procedures and confirm they

include clear rules for transfer and installation, which includes
notification to the GSMA compliance email address.

For a sample of certificates, confirm that they are transferred and

installed in accordance with procedures and the GSMA has been
informed of the certificates.

Review the solution architect and confirm that it fully describes all
of the data and assets to be used within the solution, together with
the security to be applied for each ES channel and for the data when
transferred with an external body (outside of the ES channels) and
for the data at rest.

Confirm that the information classification has been defined for

each type of data and that the handling of the data in transit and at
rest is aligned to the classification and handling scheme.
Review the network diagram and confirm that there is no direct
access to the secure network (requirement 10.4.2). Review the
firewall rules to verify that connections follow the principle of
minimum access.

Review the roles and responsibilities matrix to confirm that there is

a segregation of administrator access (covered as part of 10.2.1).

Where individuals have multiple levels of administrator access,

confirm that a risk has been raised in the risk register (requirement
1.2.1) and additional controls are in place. Review the internal
checks and audit programme (1.4.1 and 10.8.1) to confirm that
these controls are subject to checks.

Review the solution architecture and confirm that it fully describes

all of the data and assets to be used within the solution, together
with the security to be applied for the data when transferred and at
rest (requirement 7.1.1), including backups (requirement 10.5.2).

Review the database servers and confirm that there are appropriate
controls in place to safeguard the data while at rest that is aligned
to the classification and handling policy.

Review the policy and confirm that all types of data have been
identified (cross-reference to the solution architecture document)
and retention periods have been defined.

For a sample of data types, review evidences to confirm that data is

not held beyond the retention period (specifically examine any data
held by the internal audit team whom may have copies of raw data).

Confirm that the internal checks and audit programme includes

reviews of systems to ensure data is not being held beyond the
retention period.
This is covered as part of 10.6.1.

Review the event management policy and procedures to confirm

that the network devices and systems are required to generate
audit logs and prevent tampering/deletion of logs and/or log
entries.

Verify the controls in place to prevent tampering (e.g. real-time

forwarding and access management).

Confirm that the internal checks and audit programme

(requirements 1.4.1 and 10.8.1) includes a review of network
devices and systems on a regular basis to confirm that they are
generating logs and forwarding logs to a repository server.

For a sample of network devices and systems, review the log entries
and trace through to the log repository.

Review the roles and responsibilities matrix and confirm that

administrators are unable to manipulate the logs.

Confirm the events that have been identified that would trigger an
alert and confirm the action that has been configured.

Review evidences of alerts (e.g. emails / SMS) and cross-reference

to the incident management system (requirement 2.3.1) to confirm
that a ticket is raised and the incident has been investigated.
Review the policy and confirm that all types of data have been
identified (cross-reference to the solution architecture document)
and retention periods have been defined.

For a sample of data types, review evidences to confirm that data is

not held beyond the retention period (specifically examine any data
held by the internal audit team whom may have copies of raw data).

Confirm that the internal checks and audit programme includes

reviews of systems to ensure data is not being held beyond the
retention period.

For a sample of network devices and systems, review the log entries
and trace through to the log repository.

Review the roles and responsibilities matrix and confirm that

administrators are unable to manipulate the logs.

Verify the controls in place to prevent tampering (e.g. real-time

forwarding and access management).

For a sample of logs, confirm that there are no sensitive data

present in clear text.
Review the solution architecture and network topology to
determine the stages where data processing takes place.

Review the controls in place to ensure that dual control is applied

(such as key management).

Review the solution architecture and confirm that controls are in

place to prevent duplicate production.

During the solution demonstration, confirm that it is not possible to

duplicate profiles.
Review the solution architecture and confirm that it fully describes
all of the data and assets to be used within the solution, together
with the security to be applied for each ES channel and for the data
when transferred with an external body (outside of the ES channels)
and for the data at rest.

Confirm that the information classification has been defined for

each type of data and that the handling of the data in transit and at
rest is aligned to the classification and handling scheme.

During the solution demonstration, confirm that all ES channels are

secure as per the solution architecture and use case specifications.

For a sample of checks, confirm that they have been undertaken in

accordance with the intended frequency.

Review a sample of checks for all areas of control and confirm that
they have been fully documented and undertaken in line with the
testing methodology.

Performed at the end of the audit: for any NCs and C- findings,
ascertain if they were covered in the scope of an internal
check/audit and identified.

Review a sample of CFSF minutes, and confirm that internal checks

and audits is a standing agenda item and progress on actions are
monitored.

Interview personnel / review HR records and confirm individuals are

appropriately trained and competent to perform their role.
Review the solution architect and confirm that it fully describes all
of the data and assets to be used within the solution, together with
the security to be applied for each ES channel and for the data when
transferred with an external body (outside of the ES channels) and
for the data at rest.

Confirm that the information classification has been defined for

each type of data and that the handling of the data in transit and at
rest is aligned to the classification and handling scheme.

During the solution demonstration, confirm that all ES channels are

secure as per the solution architecture and use case specifications.

Review the classification level assigned to all aspects of data within

the solution and confirm they are aligned to the GSMA FS.08 Annex
A class 1 and class 2 types. Cross-reference the handling guide for
the classification level and confirm it is appropriate.

During the solution demonstration, confirm that all ES channels are

in place in accordance with data classification policy and as per their
description in the solution architecture and functionality
documentation.

Review the solution architecture to confirm how customer data is

protected.

During the solution demonstration, confirm that customer data is

protected. This may also require a review of the database
encryption.

Review the solution architecture to confirm how customer data is

protected.

During the solution demonstration, confirm that customer data is

protected. This may also require a review of the database
encryption.
Review the network diagrams (physical, logical, data flow, and rack)
and solution architecture to confirm that all network devices and
systems are defined and connections are secured.

During the solution demonstration, confirm that entity authenticity

is verified.

This is covered as part of 10.6.1.

Review the event management policy and procedures to confirm

that the network devices and systems are required to generate
audit logs and prevent tampering/deletion of logs and/or log
entries.

Verify the controls in place to prevent tampering (e.g. real-time

forwarding and access management).

Confirm that the internal checks and audit programme

(requirements 1.4.1 and 10.8.1) includes a review of network
devices and systems on a regular basis to confirm that they are
generating logs and forwarding logs to a repository server.

For a sample of network devices and systems, review the log entries
and trace through to the log repository.

Review the roles and responsibilities matrix and confirm that

administrators are unable to manipulate the logs.
Confirm the events that have been identified that would trigger an
alert and confirm the action that has been configured.

Review evidences of alerts (e.g. emails / SMS) and cross-reference

to the incident management system (requirement 2.3.1) to confirm
that a ticket is raised and the incident has been investigated.

Review the policy and confirm that all types of data have been
identified (cross-reference to the solution architecture document)
and retention periods have been defined.

For a sample of data types, review evidences to confirm that data is

not held beyond the retention period (specifically examine any data
held by the internal audit team whom may have copies of raw data).

Confirm that the internal checks and audit programme includes

reviews of systems to ensure data is not being held beyond the
retention period.

Review the IT security policy and confirm it covers all aspects of

network and system security (defined within the requirements of
section 10, below)

For a sample of roles, cross-reference to the organisational structure

for completeness.

Review the roles and responsibilities matrix to confirm that there is

a segregation of administrator access.

Where individuals have multiple levels of administrator access,

confirm that a risk has been raised in the risk register (requirement
1.2.1) and additional controls are in place. Review the internal
checks and audit programme (1.4.1 and 10.8.1) to confirm that
these controls are subject to checks.
Review the policy and confirm that it includes details of how
requests are made and approved.

Obtain a list of individuals with permanent physical access. For a

sample, confirm that there is a ticketed request, which has been
appropriately approved.

Obtain an activity report from the BAS system. Identify individuals

whom do not have permanent access, and for a sample, confirm
that there is a ticket request, which has been appropriately
approved. Review the account for these individuals within the BAS
and confirm that access is no longer valid.

Obtain a list of contractors and security personnel with physical

access, if handled differently to permanent/temporary access. For a
sample, confirm that there is a ticketed request, which has been
appropriately approved.

During the audit, confirm that employees are wearing their ID

badges at all times.

Review the access management policy and supporting procedures

and confirm that they sufficiently define the processes for creating,
modifying and deleting access rights and how these accounts are
monitored.

For a sample of accounts, confirm that a ticket exists, which includes

approval.

Obtain a list of current accounts and confirm that all individuals are
listed in the organisational structure (2.1.1). Where the accounts are
machine/service, confirm that purpose of the account is defined.

For a sample of network devices and systems, review the actual

accounts, and confirm they are as per the approved list.

Confirm that the internal checks and audit programme

(requirements 1.4.1 and 10.8.1) includes a review of access rights on
a regular basis (quarterly) and a review of activity (monthly).

For a sample of the checks, review the evidence of testing

performed and confirm that all anomalies are identified, reported,
and appropriate action taken.
Review the password policy and confirm that it is applicable to all
account types and specifies the password characteristics.

Review the password policy (or alternative policy, such as access

control policy) and confirm that the account lockout and screen lock
parameters are also defined.

For a sample of network devices and systems, confirm that the

password policy has been applied.

Review the password policy and confirm that it states that

additional controls must be in place for network devices and
systems that cannot support the password policy.

Ascertain whether all network devices and systems that cannot

support the password policy have been identified and the risk has
been raised (requirement 1.2.1).

For a sample of network devices and systems, confirm that the

password policy has been applied.

For a sample of accounts with generic IDs (such as 'Admin'), confirm

that these accounts are being managed under split knowledge.
Review the access management policy and confirm that remote
access is appropriately defined, including the mechanisms for
gaining access. Cross-reference this to the logical network diagram.

Ascertain whether remote access takes place from a dedicated

physical location. Inspect this location and confirm that appropriate
physical controls are applied (per section 5).

Review the configuration of remote access to confirm that

appropriate security is in place (e.g. multi-factor authentication,
encryption, etc.).

Review the list of individuals with remote access and cross-

reference this to the organisational chart (1.2.1) and roles and
responsibilities matrix.

For a sample of accounts, review the corresponding ticket to

confirm that access has been approved.

Confirm that all remote access activity is logged and alerts are
generated for any suspicious activity (requirement 10.6.1) and
investigated in line with the incident management procedures
(requirement 2.3.1).

Confirm that reviews of remote access is included within the

internal checks and audit programme (1.4.1 and 10.8.1) and subject
to regular inspections for:
- validation of current users (e.g. quarterly)
- activity (e.g. monthly)

Review the access management policy/procedure and confirm that

account lockouts have been defined.

Review the configuration of remote access and confirm that the

lockouts have been applied (cross reference to requirement 10.5.1
(vii).
Review the network diagrams (physical, logical, data flow, and rack)
to confirm that all network devices and systems are defined and
connections are secured.

Physical verify the physical rack diagram to the content of the racks
and asset register.

Review the network topology and asset register and confirm that a
security in depth model is adopted whereby there is no single point
of failure (e.g. different makes and model of firewall are deployed).

Review the network diagram and confirm that there is no direct

access to the secure network. Review the firewall rules to verify that
connections follow the principle of minimum access.

Review the network topology and asset register for firewalls. For
each make and model of firewall, confirm that there is a hardening
standard in place, which is based on the industry good practice and
vendor recommendations.

For a sample of firewalls, confirm that the configuration is aligned to

the hardening standard.

Review the approved firewall ruleset against the network topology

to confirm that the minimum access is permitted.

For a sample of firewalls, confirm that the firewall rules

implemented agree to the approved firewall ruleset.

Review the change management policy and procedure and confirm

that all firewall changes are subject to the policy/procedure.

Review the firewall ruleset and for a sample of rules, confirm that
there is a change request, which has been approved.

Review the change requests for firewall rules. For a sample, confirm
the approved changes have been implemented and tested in
accordance with the request.
Confirm that there is an IDS in place, either as part of the firewalls
or as a separate installation. Review the hardening standard against
the actual configuration.

Review the network topology for deployment of IDS to confirm that

all traffic is subject to analysis and logging.

Confirm that the IDS is generating logs and events have been
identified to trigger alerts (requirement 10.6.1) and incidents are
investigated (requirement 2.3.1).

Review the programme for penetration testing (or equivalent policy)

to confirm that penetration tests are performed on a regular basis
and the scope of testing to be applied and approach (e.g. a different
pen testing company is used each time to minimise complacency).

Review the last internal and external penetration test reports and
confirm that all findings have been logged (e.g. risk register
(requirement 1.2.1), ticketing system, and change management
system, with all changes being approved and tracked.

Where possible, review re-testing reports to confirm that

appropriate action has been taken to address the findings.

Review the network topology and asset register to confirm that

availability has been considered throughout the design and there is
no single point of failure.

Review the risk register (requirement 1.2.1) and business continuity

plan (requirement 1.3.1) and confirm that lack of availability due to
threats such as DoS and DDoS have been identified and appropriate
controls are in place it mitigate these threats, such as a scrubbing
service on demand.

Review the procurement procedure to confirm that security is

considered as part of the decision making, such as security in depth
model.

Review the network topology diagram and asset register to confirm

that there are no single points of failure.

Confirm that the internal checks and audit programme includes

regular checks of assets.
Review the patch management policy and confirm that all network
devices and systems are to be patched up-to-date with the latest
patches, once tested and approved for deployment.

Review the asset management lifecycle (referenced in requirement

2.2.3) and confirm that there is a process to replace hardware that
is end-of-life.

For a sample of network devices and systems, confirm that the

latest security and critical patches have been installed in line with
the patch management policy and change management policy.

Review the network topology and asset register for systems. For
each make and model, confirm that there is a hardening standard in
place, which is based on the industry good practice and vendor
recommendations.

For a sample of systems, confirm that the configuration is aligned to

the hardening standard.

Review the internal checks and audit programme and confirm that it
includes actual configuration setting of systems to the approved
baseline. For any variations identified, confirm that an incident was
raised and investigated.

For a sample of systems, review the configuration settings to ensure

that they are hardened.
Review the change management policy and procedure and confirm
that all system changes are subject to the policy/procedure.

For a sample of systems, review the configurations and confirm that

there is a change request, which has been approved.

Review the change requests for system configurations. For a sample,

confirm the approved changes have been implemented and tested
in accordance with the request.
Review the vulnerability management policy and supporting
procedures and confirm that it defines the need to subscribe to
various security websites, vendors, newsfeeds, etc. in order to
identify potential threats early.

Review the asset inventory and ascertain if security feeds have been
established for each asset and incidents are raised, when
vulnerabilities are reported, and investigated.

For a sample of alerts from vendors, examine the corresponding

incident ticket to confirm that prompt actions were taken to assess
the level of risk.

Review the policy/procedures to confirm that internal and external

vulnerability scans are performed on a regular basis by
appropriately qualified companies/individuals.

Confirm that expected actions are also defined, together with

targets for resolution.

Review the last two sets of internal and external vulnerability scan
reports and confirm that all network devices and systems were in
scope for the scan (compare to the network topology and asset
inventory).

Confirm that all findings from the scans have been logged (e.g. risk
register (requirement 1.2.1), ticketing system, and change
management system, with all changes being approved and tracked.

Where possible, review evidences (e.g. the next scan) to confirm

that actions have resolved the issues raised in the findings.

Review the malware prevention strategy and confirm it defines that

a malware perimeter for the site has been established and
appropriate controls defined (such as anti-virus software and
scanning).

Review the asset inventory and for a sample of assets, confirm that
anti-virus is installed and configured to look for and install signature
updates at least once a day and actively scan for viruses.

Confirm that there is a procedures for handling viruses, which

includes quarantine and incident management.
Review the policy for session timeouts and confirm that these
include idle terminals and connections (such as VPN).

Review the asset inventory and for a sample of assets, confirm that
session timeouts for idle terminals (e.g. screensavers) have been
configured (remote access session timeout should be reviewed as
part of requirement 10.3.4).

Review the asset management policy (requirement 2.2.3) and

ensure it covers the replacement of systems that are no longer
supported by updates (requirement 10.5.1 (ii)) and the
decommissioning/decertification procedures for all assets that are
no longer required.

Confirm that the procedures include how the assets should be

handled (e.g. data removed) before the asset is removed from the
H.S.A. If the asset is physically destroyed, there is evidence such as a
destruction record or certificate of destruction (if undertaken by a
3rd party).

Review the asset inventory and change management system for

evidences of decommissioned assets, and review evidences to
confirm that assets were handled appropriately.

Review the backup and retention policy and confirm that all types of
data have been identified, together with their backup schedules and
methods. Cross-reference this to the BCP with regard to availability.

For a sample fo backup methods, confirm that the process is

performed securely, including any offsite storage.

Review the event management policy and procedures to confirm

that the network devices and systems are required to generate
audit logs and prevent tampering/deletion of logs and/or log
entries.

Verify the controls in place to prevent tampering (e.g. real-time

forwarding and access management).
Confirm that the internal checks and audit programme
(requirements 1.4.1 and 10.8.1) includes a review of network
devices and systems on a regular basis to confirm that they are
generating logs and forwarding logs to a repository server.

For a sample of network devices and systems, review the log entries
and trace through to the log repository.

Confirm the events that have been identified that would trigger an
alert and confirm the action that has been configured.

Review evidences of alerts (e.g. emails / SMS) and cross-reference

to the incident management system (requirement 2.3.1) to confirm
that a ticket is raised and the incident has been investigated.

Ascertain all external service providers where there is a dependency

on security. For a sample, review the contracts (requirement 2.4.1)
and confirm that they include SLAs.

For a sample of providers, ascertain what monitoring takes place

(such as contract liaison meetings) and the levels of assurance over
the provider for security (e.g. SOC Type II report, internal audits,
etc.).

For a sample of checks, confirm that they have been undertaken in

accordance with the intended frequency.

Review a sample of checks for all areas of control and confirm that
they have been fully documented and undertaken in line with the
testing methodology.

Performed at the end of the audit: for any NCs and C- findings,
ascertain if they were covered in the scope of an internal
check/audit and identified.
Review a sample of CFSF minutes, and confirm that internal checks
and audits is a standing agenda item and progress on actions are
monitored.

Interview personnel / review HR records and confirm individuals are

appropriately trained and competent to perform their role.

Review the SDLC methodology and confirm that security is defined

at the requirements stage.

For a sample of security requirements, confirm that they are tracked

through the lifecycle (e.g. such as a user story).

Confirm that the solution has been subjected to appropriate

penetration testing.
 Preparation for Online Evidence Review
(A.7 of Annex A to GSMA SAS Remote Audit Policy)

Auditee Evidence Preparation to satisfy detailed test (ensure evidence is

available to share via remote sessions)

Please refer to detailed testing within this document and FS.18 for further clarity.
Document Requirement Refs.

Security policy 1.1.1

Information security management system (ISMS) (typically those listed below,
1.1.2
but this is not a definitive list)
• Risk management policy 1.2.1, 5.1.1
• Security strategy 1.2.1, 5.1.1
• Business continuity policy 1.3.1
• Asset management policy 2.2.3, 7.2.1
• Incident management policy 2.3.1
• Data classification policy 3.1.1
• Access Management Policy 3.2.1, 5.3.1, 10.2.1, 10.4.2
• Human resources policy 4.2.2, 4.3.3
• Physical security policy Section 5
• Cryptographic policy Section 6
• IT security policy 10.1.1
• Password policy 10.3.3
• Change management policy 10.4.3, 10.5.1
• Vulnerability & patch management policy 10.4.4
• Backup and recovery policy 10.5.2
• 3rd Party management policy 2.4.1, 10.7.1
• Secure software development life cycle SDLC policy 10.9.1
• Clear desk policy 3.2.2
• Whistleblowing policy 4.4.1
• Disciplinary policy 4.4.2
• Data retention & destruction policy 7.2.3, 7.4.1, 7.4.2

Employees’ declarations of acceptance of the information security policy 1.1.2, 4.3.1

Risk management methodology / procedures 1.2.1

Risk assessments 1.2.1, 5.1.1
Risk registers 1.2.1
Business continuity plan and disaster recovery plan 1.3.1
Business impact assessments 1.3.1
Business continuity planning and disaster recovery test plans and evidence of
1.3.1
testing
Internal checks and audit programme 1.4.1, 5.5.1, 7.7.1, 10.8.1
List of key controls 1.4.1, 5.5.1, 7.7.1, 10.8.1

Internal checks and audit methodology / procedures 1.4.1, 5.5.1, 7.7.1, 10.8.2

Organisational Chart for SAS-SM, including security responsibilities 2.1.1

Cross-function security forum meeting minutes / action tracking 2.1.2
Defined security responsibilities (job descriptions) 2.2.1, 2.2.2, 4.1.1

Asset inventories and audit trails 2.2.3, 7.2.1

Incident response plans 2.3.1
List of reported incidents 2.3.1
Customer and supplier contracts 2.4.1
Supplier insurance certificates 2.4.1
Data classification and handling procedures 3.1.1
Business processes relating to SAS-SM 3.1.1
Network diagrams and data flow diagrams 3.1.1, 10.4.2
3.2.1, 5.3.1, 10.2.1, 10.3.2,
Access management procedures
10.3.3, 10.3.4
Roles and responsibilities matrices 3.2.1, 10.2.1, 10.3.2
Pre-employment / ongoing screening procedures and checklists 4.2.1
Evidences of pre-employment and ongoing screening 4.2.1
Human resources procedures and checklists 4.2.2, 4.3.3, 4.5.1
List of starters, leavers, and changes in job roles for SAS-SM during past 12
4.2.2, 4.3.3, 4.5.1
months
Evidences of completed checklists 4.2.2, 4.3.3, 4.5.1
Security awareness training procedures 4.3.3
Evidence of security awareness training and course material 4.3.3
Whistleblowing procedures 4.4.1
Disciplinary procedures 4.4.2
Grievance procedures 4.4.2
Physical security procedures and operations manual Section 5
Site map with security controls 5.2.1, 5.2.2
Visitor registration and logbooks 5.3.1
Badge access system logs/audit trails 5.3.2, 10.3.1
6.1.1, 6.2.2, 6.4.2, 6.5.1,
Key/certificate management procedures
6.6.1

6.1.1, 6.2.2, 6.4.2, 6.5.1,

Key/certificate audit trails
6.6.1

Key management personnel records 6.2.1

Key and certificate architecture and lifecycle details 6.3.1

HSM FIPS certificate and configuration settings 6.4.3
Data transfers and protections (linked to data flows) 7.1.1
Data retention and destruction procedures and audit trails 3.1.1, 7.2.3, 7.4.1, 7.4.2
IT procedures and evidences Section 10
• Network device hardening and configurations 10.4.1, 10.4.3
• System hardening and configurations 10.5.1
• Vulnerability Management 10.4.4
• Change Management 10.4.3, 10.5.1
• Backup and Restoration 10.5.2
• Supplier management 10.7.1
• Secure SDLC procedures 10.9.1
 Required for Offline
Comment Documentation
Review

Yes
Yes

Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Including site classification and controls Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Contract of employment; NDAs; declaration form (manual or
electronic)
Yes

Relating to SAS-SM
Yes

Yes
Yes
Detailing how each check/audit is performed, reporting
requirements, and action tracking
Yes
Security steering committee
List of duties

Hardware, software, data

Liability clauses

Yes
Yes
Yes
Yes
Grant / amend / remove access, Remote access, Passwords

Physical access, logical access. Yes

Yes

Appointments, change of jobs, terminations Yes

Yes

Yes
eLearning reports, attendance registers, etc.
Yes
Yes
Yes
Yes
Yes

Yes

Key management system / HSM logs, key/certificate

inventories, key ceremony forms, safe inventories and in/out
logbooks, etc.
Appointments, reappointments, roles and responsibilities,
declarations, training.

FIPS 140-2 level 3 and configured to meet this level

Protocols in use, encryption applied, etc. Yes

Firewalls, IDS/IPS, switches

Vulnerability scanning, penetration testing, antivirus

Key external dependences

Required for Online
Document Title
Evidence Review

Yes

Yes
Yes

Yes
Yes

Yes

Yes
Yes

Yes
Yes
Yes
Yes
Yes

Yes

Yes

Yes

Yes
Yes

Yes

Yes

Yes
Yes

Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
File Reference