Version Date Author

1.0 ### Neil Shepherd, SRC GmbH &

Andrew Hutchins, NCC Group
1.1 ### Andrew Hutchins, NCC Group
1.2 ### Andrew Hutchins, NCC Group
1.3 Monday, May 9, 2022 David Maxwell, GSMA
1.4 Saturday, May 21, 2022 Andrew Hutchins, NCC Group
Description
First released version for CSPs.

Updated to reflect changes within version 7.0 of FS.17.

Updated to reflect changes in CSR for managed HSM requirements
Removed FS.17 references. Updated introduction.
Rewording of introduction for applicability for both onsite and offsite assessments
Introduction
The purpose of this workbook is to help a cloud service provider (CSP) auditee prepare for an SAS-SM audit, held either on
Consolidated Security Requirements and Guidelines that are applicable to SAS-SM and information on the type of informa

Auditees are expected to review this workbook, together with the following:
- FS.08 SAS-SM Standard,
- FS.09 SAS-SM Methodology,
- FS.18 SAS Consolidated Security Requirements and Guidelines
And for remote audits:
- FS.09C19 SAS-SM Covid-19 Methodology Variations v1_3
Supporting documents:
- SAS-SM audit analysis
- Cloud Deployment of Subscription Management Solutions - Guidance for SAS-SM Auditees

This workbook does not replace the need for the auditee to have a full understanding of the SAS 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
added to the Document List Worksheet.

For remote audits, as this phase will be undertaken offline, the auditors need to understand how you have addressed each
that you have to ensure compliance with the FS.18 Consolidated Security Requirements and Guidelines).

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 demonstrate that the controls are working as per described in the policies an
details of what types of evidences the auditors will be looking for. During the preparation and planning meetings, the audi
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 H-K, and M
Document List columns F and G (for those evidences marked with a 'Yes' in column F of the Auditee Preparation Workshee
 GSMA FS.18 SAS Consolidated Security Requirements and Guidelines (CSRG) version 8.0

Sub-Sect
Section Sub-Sec Req.
Desc

1 - Policy, Strategy, 1.1 Policy 1.1.1

and Documentation

1 - Policy, Strategy, 1.1 Policy 1.1.2

and Documentation

1 - Policy, Strategy, 1.2 Strategy 1.2.1

and Documentation
1 - Policy, Strategy, 1.3 Business 1.3.1
and Documentation Continuity
Planning
1 - Policy, Strategy, 1.4 Internal 1.4.1
and Documentation audit and
control

2 - Organisation and 2.1 Organisation 2.1.1

Responsibility

2 - Organisation and 2.1 Organisation 2.1.2

Responsibility

2 - Organisation and 2.2 Responsibiliti 2.2.1

Responsibility es

2 - Organisation and 2.2 Responsibiliti 2.2.2

Responsibility es
2 - Organisation and 2.2 Responsibiliti 2.2.2
Responsibility es

2 - Organisation and 2.2 Responsibiliti 2.2.3

Responsibility es

2 - Organisation and 2.2 Responsibiliti 2.2.4

Responsibility es

2 - Organisation and 2.3 Incident 2.3.1

Responsibility response
and
reporting
2 - Organisation and 2.4 Contracts 2.4.1
Responsibility and liabilities

2 - Organisation and 2.4 Contracts 2.4.2

Responsibility and liabilities
3 - Information 3.1 Classification 3.1.1

3 - Information 3.2 Data and 3.2.1

media
handling

3.2.2

4 - Personnel 4.1 Security in 4.1.1

Security job
description
4 - Personnel 4.2 Recruitment 4.2.1
Security screening

4 - Personnel 4.3 Acceptance 4.3.1

Security of security
rules

4 - Personnel 4.3 Acceptance 4.3.2

Security of security
rules

4 - Personnel 4.3 Acceptance 4.3.3

Security of security
rules
4 - Personnel 4.4 Incident 4.4.1
Security response
and
reporting

4 - Personnel 4.4 Incident 4.4.2

Security response
and
reporting

4 - Personnel 4.5 Contract 4.5.1

Security termination

5 - Physical Security 5.1 Security plan 5.1.1

5 - Physical Security 5.2 Physical 5.2.1
protection
5 - Physical Security 5.2 Physical 5.2.2
protection

5 - Physical Security 5.3 Access 5.3.1

control
5 - Physical Security 5.3 Access 5.3.2
control

5 - Physical Security 5.4 Security Staff 5.4.1

5 - Physical Security 5.5 Internal 5.5.1
audit and
control

6 - Certificate and 6.1 Classification 6.1.1

key management
6 - Certificate and 6.2 Roles and 6.2.1
key management responsibiliti
es

6 - Certificate and 6.2 Roles and 6.2.2

key management responsibiliti
es
6 - Certificate and 6.2 Roles and 6.2.2
key management responsibiliti
es

6 - Certificate and 6.3 Cryptographi 6.3.1

key management c key
specification
6 - Certificate and 6.4 Cryptographi 6.4.1
key management c key
management

6 - Certificate and 6.4 Cryptographi 6.4.2

key management c key
management

6 - Certificate and 6.4 Cryptographi 6.4.3

key management c key
management
6 - Certificate and 6.5 Auditability 6.5.1
key management and
accountabilit
y

6 - Certificate and 6.6 GSMA Public 6.6.1

key management Key
Infrastructur
e (PKI)
Certificates

6 - Certificate and 6.6 GSMA Public 6.6.2

key management Key
Infrastructur
e (PKI)
Certificates
6 - Certificate and 6.6 GSMA Public 6.6.3
key management Key
Infrastructur
e (PKI)
Certificates

6 - Certificate and 6.6 GSMA Public 6.6.4

key management Key
Infrastructur
e (PKI)
Certificates

6 - Certificate and 6.7 HSM as a 6.7.1

key management managed
service

6 - Certificate and 6.7 HSM as a 6.7.2

key management managed
service
6 - Certificate and 6.7 HSM as a 6.7.3
key management managed
service

6 - Certificate and 6.7 HSM as a 6.7.4

key management managed
service
7 - Sensitive Process 7.1 Data transfer 7.1.1
data management

7 - Sensitive Process 7.2 Sensitive 7.2.1

data management data access,
storage and
retention

7 - Sensitive Process 7.2 Sensitive 7.2.2

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

7 - Sensitive Process 7.4 Auditability 7.4.1

data management and
accountabilit
y
7 - Sensitive Process 7.4 Auditability 7.4.2
data management and
accountabilit
y

7 - Sensitive Process 7.4 Auditability 7.4.3

data management and
accountabilit
y

7 - Sensitive Process 7.5 Duplicate 7.5.1

data management production
7 - Sensitive Process 7.6 Data 7.6.1
data management integrity

7 - Sensitive Process 7.7 Internal 7.7.1

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

8 - SM-DP, SM-SR, 8.1 SM-DP, SM- 8.1.2

SM-DP+ and SM-DS SR, SM-DP+
Service Management and SM-SR
Service

8 - SM-DP, SM-SR, 8.1 SM-DP, SM- 8.1.3

SM-DP+ and SM-DS SR, SM-DP+
Service Management and SM-SR
Service

8 - SM-DP, SM-SR, 8.1 SM-DP, SM- 8.1.4

SM-DP+ and SM-DS SR, SM-DP+
Service Management and SM-SR
Service
8 - SM-DP, SM-SR, 8.2 Remote 8.2.1
SM-DP+ and SM-DS Entity
Service Management Authenticati
on

8 - SM-DP, SM-SR, 8.3 Audit trails 8.3.1

SM-DP+ and SM-DS
Service Management
8 - SM-DP, SM-SR, 8.3 Audit trails 8.3.2
SM-DP+ and SM-DS
Service Management
10 - Computer and 10.1 Policy 10.1.1
network
management

10 - Computer and 10.2 Segregation 10.2.1

network of duties
management
10 - Computer and 10.3 Access 10.3.1
network control
management

10 - Computer and 10.3 Access 10.3.2

network control
management
10 - Computer and 10.3 Access 10.3.3
network control
management
10 - Computer and 10.4 Remote 10.4.1
network Access
management

10 - Computer and 10.4 Remote 10.4.2

network Access
management

10 - Computer and 10.4 Remote 10.4.3

network Access
management
10 - Computer and 10.4 Remote 10.4.4
network Access
management

10 - Computer and 10.4 Remote 10.4.5

network Access
management

10 - Computer and 10.4 Remote 10.4.6

network Access
management
10 - Computer and 10.4 Remote 10.4.7 (i)
network Access
management

10 - Computer and 10.4 Remote 10.4.7 (ii)

network Access
management
10 - Computer and 10.4 Remote 10.4.7 (iii)
network Access
management

10 - Computer and 10.4 Remote 10.4.7 (iv)

network Access
management

10 - Computer and 10.4 Remote 10.4.7 (v)

network Access
management

10 - Computer and 10.5 Network 10.5.1

network Security
management
10 - Computer and 10.5 Network 10.5.2
network Security
management

10 - Computer and 10.5 Network 10.5.3

network Security
management
10 - Computer and 10.5 Network 10.5.4
network Security
management

10 - Computer and 10.5 Network 10.5.5

network Security
management

10 - Computer and 10.6 System 10.6.1 (i)

network Security
management
10 - Computer and 10.6 System 10.6.1 (ii)
network Security
management

10 - Computer and 10.6 System 10.6.1 (iii)

network Security
management
10 - Computer and 10.6 System 10.6.1 (iv)
network Security
management

10 - Computer and 10.6 System 10.6.1 (v)

network Security
management
10 - Computer and 10.6 System 10.6.1 (vi)
network Security
management

10 - Computer and 10.6 System 10.6.1 (vii)

network Security
management

10 - Computer and 10.6 System 10.6.1 (viii)

network Security
management

10 - Computer and 10.6 System 10.6.2

network Security
management
10 - Computer and 10.7 Audit and 10.7.1
network monitoring
management

10 - Computer and 10.8 External 10.8.1

network facilities
management management

10 - Computer and 10.9 Internal 10.9.1

network audit and
management control
management control

10 - Computer and 10.1 Software 10.10.1

network Developmen
management t

10 - Computer and 10.1 Software 10.10.2

network Developmen
management t
10 - Computer and 10.11 Multi- 10.11.1
network Tenancy
management Environment
s

10 - Computer and 10.11 Multi- 10.11.2

network Tenancy
management Environment
s

10 - Computer and 10 Multi- 10.11.3

network Tenancy
management Environment
s

10 - Computer and 10 Multi- 10.11.4

network Tenancy
management Environment
s
10 - Computer and 10 Multi- 10.11.5
network Tenancy
management Environment
s
ed Security Requirements and Guidelines (CSRG) version 8.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.
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.

Where activities within scope of SAS certification are outsourced or

sub-contracted, partners providing or operating these services shall be
contractually responsible to ensure an appropriate level of compliance
with the SAS requirements.

(i) Responsibilities that fall within the scope of the auditee’s SAS
certification shall be clearly documented and agreed.

(ii) Contracts shall include a “right-to-audit” clause (or equivalent

mechanism) to:
- Enable auditees to confirm that contractual responsibilities and
obligations are maintained at the required level by the outsourcing
partner / subcontractor.
- Include the right of the auditee to require the outsourcing partner /
sub-contractor to participate in the SAS audit process, where
applicable.
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
of, authorised and unauthorised activities within the SP.
- 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.
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.
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.

The auditee shall only use an HSM that is managed by an SAS certified
data centre or cloud region.
In addition to the requirements of 2.4.2, the specific responsibilities
assignment shall be documented and agreed between the auditee and
the CSP managing the HSM.

Design, implementation and controls must ensure that cryptographic

keys and certificates are only accessible to the SM service provider.
Remote key management activities shall be possible only upon
demonstrating a trusted path.
(i) Remote key management activities shall be performed from a
certified environment in accordance with the requirements of section
6.4.1 and 10.4.
(ii) Remote key management activities shall be performed through a
point-to-point secure channel from the SM service provider’s key
management system to the HSM. The channel shall provide
confidentiality, integrity, authenticity, replay protection and forward
secrecy.
(iii) The SM service provider shall have controls in place restricting
management remote access to trusted sources and authorised
personnel only.

An HSM supporting partitions must have all its partitions allocated to a

single SM service provider.
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).
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.
Where remote access is implemented it shall:
• Enforce appropriate protection of sensitive systems, networks and
information.
• Be implemented based on strict principles of minimum access.
• Be fully auditable.
• Be subject to a clear, documented risk assessment.
• Be governed by a defined remote access policy and procedure.

Remote access controls secure the connection from the remote user to
the target environment. All operations carried out across the remote
access connection shall enforce an equivalent security level to
corresponding activities conducted locally on-site.

Where remote access for operational read-only monitoring of systems

is granted, such connections shall take place with/via systems on a DMZ
rather than directly into a high security network.
Access to view sensitive data shall not be possible.
Where remote access for connection to pre-defined services is granted,
such connections shall take place with/via systems on a DMZ rather
than directly into a high security network.
Access to view sensitive data shall not be possible.

Where remote interactive access to sensitive systems and networks

within SAS certified sites is granted for administration or operational
reasons, such access shall take place from clearly designated, physically
controlled environments. The originating system shall have at least the
same level of physical and logical security controls as the target
systems, up to the level required for SAS compliance.

Remote access carried out other than according to 10.4.3, 10.4.4 and
10.4.5 shall not normally be accepted at SAS certified sites.
Where auditees wish to utilise other solutions as exceptions to those
normally accepted they shall provide evidence that either:
• The remote access does not allow access to networks, systems or
information within the scope of SAS certification.
Or, for SAS-SM only:
• A full and appropriate risk assessment, accepted by the audit team
prior to implementation, has been conducted
that considers both the access to systems and the visibility of sensitive
information.
And
• The site containing the endpoint systems is owned by the auditee or
its contracted supplier(s).
And
• The remote access is temporary, monitored and controlled in real-
time from a SAS-SM certified environment, with no ability to export
data.
In all cases, controls described in 10.4.7 shall apply.
Endpoint security
The security of the endpoint from which remote access originates shall
enforce appropriate logical and physical security controls to ensure a
level of protection equivalent to those applied to direct access to the
target system. Specifically, endpoints shall be:
• Positively identified, with access strictly limited to pre-authorised
devices that are:
o Owned and controlled by the auditee organisation;
o Subject to appropriate hardening controls;
o Configured according to a defined security policy;
o Up-to-date with the latest security patches at the time of the
connection.
• Only located in clearly designated physically secure environments to
which access is controlled on strict-need-to-be-there principles.
• Connected to a local network dedicated to the purpose of remote
access to sensitive network systems that can only be accessed from
within the designated physically secure environments.

Security of the channel

The channel used to connect from the endpoint network to the target
network environment shall be secured:
• End-to-end between devices that are configured and managed under
physical and logical security controls within the scope of the SAS
certification process.
• Using appropriate technologies to ensure the required level of
security.
o Keys and credentials used for authentication and encryption of the
channel should be generated, stored and exchanged according to
secure processes.
Security of the target network
The remote access channel used for user access shall terminate in a
dedicated remote access network containing one or more jump hosts
configured to control and monitor access for authorized endpoints and
end users to connect to pre-determined target systems.
The remote access network shall be configured to permit access:
• Inbound only via the secure channel.
• Outbound:
o Via one or more firewalls.
o Only to those target systems to which remote access is specifically
required.
o Only using pre-determined methods of connection (e.g. RDP, SSH)
for each system.
Jump hosts shall be used within the frontend/DMZ zone to connect to
devices or servers in that zone.
Additional jump hosts shall be used within the backend zone to connect
to devices or servers in that zone.
A jump host shall be used within the relevant network security zone in
which the targeted servers are logically and physically located.

Authentication
Remote user access mechanisms must employ enhanced authentication
mechanisms (e.g. multi-factor authentication), whenever remote access
is granted:
• across networks of lower security level than that being connected to
• from off-site locations.

Audit trails and logs

Monitoring and full logging shall be in place to ensure full traceability of
all access sessions.
Integrity of these logs and logging mechanisms shall be protected to
prevent modification, deletion or disabling.

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.
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.

The software development processes for applications and bespoke

software deployed within the SM environment shall follow industry
best practices for development of secure
systems.
Multi-tenant solutions must prevent cross-contamination of assets
between different customers.

Multi-tenant solutions on the same physical hardware shall ensure

customer data is logically segregated between different customers

Each customer running their own applications must use a unique ID for
that customer for the running of these application processes

Restrictions shall be put in place for all customers on shared

infrastructure by restricting use of shared system resources.
The auditee shall ensure that customer data is only stored within SAS
certified physical locations, including any Sites where data may be
replicated to as part of business continuity
plans, meeting all requirements detailed in section 5 of this document.
 Cloud Deployment of Subscription Management
Solutions - Guidance for SAS-SM Auditees

Applicable to Cloud Service Provider?

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

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
Yes

Yes

Yes

Yes

Yes
Yes

Yes

Yes

Yes

Yes

Yes
Yes

Yes

Yes

Yes

Yes

Yes
Yes

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes
Yes

No

No

No

No

No

No

No

Yes

No
No

No

No

No

No

No
No

No

No

No

No

No

No
Yes

Yes

Yes

No

No

No

No

No

No
No

No

Yes

Yes

Yes

Yes

Yes
Yes

Yes

Yes

Yes

Yes
No

No

No

No
No

No

No
No

No

No

No

No

No
No

No

No

No

No

No
No

No

No

No
No

No

No
No

No

No

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

Yes
Yes

Yes

Yes
Yes

Yes

Yes

Yes
Yes

Yes

Yes

Yes
Yes

Yes

Yes

Yes

Yes
Yes

Yes

Yes

Yes

No

No
Yes

Yes

Yes

Yes
Yes
 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.

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
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.

Agreements should be established between vendor and third parties covering the
specific responsibilities falling within the scope of the third party services being provided
and should include the "right-to-audit" or similar mechanism to ensure SAS-SM
compliance.
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 / ACS 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
- 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 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.

Any auditee offering hardware security modules (HSM) managed as a service (see section
6.7) must ensure that the HSMs are configured, managed and operated in-line with the
following requirements:
• managed consistent with the requirements in section 10
• operated in an environment consistent with the requirements of section 5
• operated by personnel subject to the controls described in section 4
• operated by personnel subject to the controls described in section 4

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.

In the case of an HSM managed as a service (see section 6.7), HSM infrastructure
management activities should be conducted using fully authorised and trained CSP
personnel.

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.

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.
For HSM managed as a service (see section 6.7), the auditee should provide a copy of the
FIPS certification proving the identification of the hardware board of the cryptographic
device used.

For HSM managed as a service (see section 6.7) equipment should be subject to a
documented commissioning, decommissioning, allocation and/or de-allocation process.

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.

Documented procedures should be defined for cloud HSM service and how HSMs are
maintained within a certified data centre / cloud region and how this compliance is
regularly reviewed.

Responsibilities of both the CSP managing the HSM and SAS-SM vendor(s) utilising the
solution should be fully defined and agreed between all parties.

Key management procedures should clearly describe how access to keys and certificates
is managed and can only be accessible by the SM service provider.

The responsibilities matrix should clearly define that only the SM service provider can
access and manange cryptographic keys and certificates defined within FS.09 Annex A.

Keys and certificates held outside of the HSM may be wrapped under a storage key that
is stored in the HSM and under the sole control of the SM service provider.
Key management procedures should clearly describe how remote connections are made
from a secure certified environment to the HSM in accordance with 6.4.1 and 10.4.

Remote connections to the HSM should only be allowed from certified physical locations
in accordance with 6.4.1 and 10.4 and must not support any other connectivity.

Remote connections must be configured to only support point-to-point secure channel

from the SM service provider's key management system to the HSM. The channel should
provide confidentiality, integrity, authenticity, replay protection and forward secrecy.

Controls must be implemented to ensure remote management access is restricted to

trusted sources and authorised personnel only. This should be implemented in line with
6.2.2 for applicable dual-control requirements and 6.4.1, 10.4.2, 10.4.5 and 10.4.7 for
applicable requirements.

HSMs used by SM service providers must have all partitions (if supported) allocated to a
single SM service provider and not shared.
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).
Remote access may be permissible under highly controlled circumstances where the risk
of such access has been fully evaluated. The risk methodology must take into account the
classification of the data on the systems being remotely accessed and whether the
remote access is:
• Read-only, providing access only to view information about the status of systems at the
certified site with no access to modify information, configuration or system operation, or
to view sensitive data.
• Connecting to a pre-defined service, designed to allow remote triggering of an activity
or function with little or no ability to affect the operation of that activity.
• Interactive or administrative access, enabling the user to modify system configuration
or operation, access or manipulate data being stored or processed, or affect the
processing of data in a way equivalent to a user on-site using a command line or
graphical environment.

The remote access mechanism will typically combine a secure channel with appropriate
user authentication and logging. Once the channel is established, the remote user will
connect to systems at the target site to perform operational activities. These activities
should always be carried out using equivalent security to activities carried out on-site.

Where an equivalent security level cannot be assured through the remote channel then
activities should not be carried out remotely.

Activities reliant on a trusted path (e.g. key ceremonies) are not currently (as of March
2020) considered to provide an equivalent level of security when carried out across a
remote connection.

Examples of such remote operational access include:

• Monitoring - access to network or system performance, status or event data published
by a system.
Examples of sensitive information include:
• Class 1 or class 2 data related to the SAS-certified activities.
• Information about system or security configuration that could be of use to a potential
attacker e.g. firewall rules.
Examples of such remote operational access include:
• Pre-defined service access – Initiating a service or process either:
o With some limited variability or user input but where the scope of activity is limited
and clearly controlled e.g. a file transfer mechanism
o As a fixed process with no variability e.g. triggering of a data processing operation.
Access to view sensitive data (key material) or access to configuration data (access
control, system configuration) must not be possible.
These activities may be carried out from outside of a high-security area where a full risk
assessment has been conducted.

Examples of sensitive systems for SAS include:

• Personalisation system
• Key management system
• Network firewalls or switches
• Back-end data transfer server
• Data generation server (SAS-UP)
Examples of such remote interactive access include:
• An interactive shell or desktop session on a workstation, server or network component
such as a firewall

Remote access to sensitive systems and networks may be carried out from a non-SAS-
certified environment only in exceptional circumstances.
Remote access may be permitted where auditees demonstrate that clear, auditable
controls are in place that prevent any access to networks, systems or information within
the scope of SAS certification, e.g. remote monitoring or logging not involving any
systems within the scope of SAS certification.
Given the distributed nature of some SAS-SM installations there may be a need for
remote access sessions to occur from physical areas of a lower security level. Such access
may be accepted provided that all of the applicable requirements in 10.4.6 are satisfied.
The work-stations utilized for remote access shall be pre-approved and subjected to a
filtering mechanism (IP filtering, MAC address…) to limit potential connections.
The devices should be hardened, up to date with the latest security patches, and running
appropriate and up-to-date anti-malware controls.
The location where the remote end point workstation is hosted should be placed either
in a HSA for the SAS–UP standard or in a secure area subject to a risk assessment in the
case of the SAS–SM standard.

Channels for remote access will often be established between different sites across
public, shared, or lower-security networks.
Channels should be established using appropriate technologies to ensure mutual
authentication and confidentiality (typically through encryption).
Appropriately configured IPsec or SSL VPNs are generally considered acceptable solutions
to provide manageable and controlled connection using pre-specified security
mechanisms.
Jump hosts provide a mechanism of authenticating a user connecting from a lower
security zone to a higher security zone when this type of connectivity would normally be
prohibited by network security policies.

Multi-factor authentication mechanisms increase the resistance any system has to

unauthorized access by requiring the end user to have knowledge of a password and a
possess access to a token device or application that generates a secondary code to be
authenticated prior to the user being granted system access.

Logs for all remote access should be generated and stored according to a defined and
documented policy. Logs should typically include:
• Authentication of the remote-user to the relevant jump host.
• Authentication of the remote-user within the target environment (e.g. Active
Directory/LDAP).
• Establishment of the VPN.
• Access to network devices, systems and applications by the remote user.
Additionally, where remote access is permitted under the exceptions described in 10.4.6,
logs should also include:
• The authentication of the user fulfilling the role of the virtual escort.
• Each action performed on the target systems.

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.

Industry best practices should be followed for all development activities and include peer
code review and approval prior to release.

There is a secure software development lifecycle (SSDLC) methodology in place, which

has been adopted for the development of all software applications deployed within the
SM environment.

The SSLDC includes security is defined at the earliest point (requirements) and tracked
through all phases. Industry best practices should be followed for all development
activities and include peer code review and approval prior to release.
There is a defined document detailing the controls established to segregate customer
environments and prevention of cross-contamination or access by unauthorised
individuals.

There is a defined document detailing the controls established to segregate customer

environments located on the same physical hardware.

Customers should be provided with access rights to their own environments only, with
no possibility of customers to access another customer’s environment

If customers are authorised to run their own applications, verify these application
processes run using the unique ID for each customer.

Procedures should be clearly defined for the protection controls preventing customer's
from monopolising system resources.

Controls should be implemented to ensure customer's cannot monopolise system

resources and ensure that all SAS-SM customer SLAs can be met.

A formal process should be in-place to review and ensure customer availability SLAs are
being met.

Server resources should be protected against exploitable vulnerabilities, such as buffer

overflows, and resources such as bandwidth, CPU and disk space, should have sufficient
restrictions in place for each customer.
Procedures should be clearly defined for the protection controls that ensure SAS-SM data
cannot be replicated or backed up to non-SAS-SM certified sites

Controls should be implemented preventing the replication of SAS-SM customer data to

non-certified SAS-SM sites.
Control Applied
(Globally [Central] / Region / Country / Building)
N/A
N/A

N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A
N/A

N/A

N/A

N/A
N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A
N/A

N/A

N/A
N/A

N/A

N/A
 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)
N/A
N/A

N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A
N/A

N/A

N/A

N/A
N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A
N/A

N/A

N/A
N/A

N/A

N/A
aration for Offline Documentation Review
Annex A to GSMA SAS Remote Audit Policy)

Auditee Documentation
(reference to the document list)
N/A
N/A

N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A
N/A

N/A

N/A

N/A
N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A
N/A

N/A

N/A
N/A

N/A

N/A
Evidences Available
(Globally [Centrally] / Region / Country / Building)
N/A
N/A

N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A
N/A

N/A

N/A

N/A
N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A

N/A
N/A

N/A

N/A

N/A
N/A

N/A

N/A
N/A

N/A

N/A
How the Auditors Will Test 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 ng 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 vendor agreements established with third party service providers and
ensure these are signed by both parties and includes details of the specific
responsibilities of the third party that they must comply with and a right to audit
as part of the SAS-SM compliance process or similar mechanism.

The vendor should ensure a process to monitor the third party's compliance for
the relevant requirements or include within their own certification assessment.
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 logical security controls of the managed HSMs to ensure that they are
meeting all relevant requirements within section 10.

Review physical security controls of the location where the managed HSMs are
deployed and operated to ensure that the requirements in section 5 are being
met.
Review all personnel requirements detailed in section 4 for individuals configuring,
managing and operating HSMs as a managed service.

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 evidences of specific training for the secure management and operations
of HSM devices for individuals involved in this process.

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.
Physically inspect each HSM to confirm that they are configured to be running in
FIPS/secure mode in accordance with the FIPS certification.

Review documented asset magagement procedures for HSMs as a managed

service to ensure this covers at least commissioning, decommissioning, allocation
and/or de-allocation process.

Inspect evidences of the lifecycle management of HSMs to validate that defined

procedures are followed and devices are securely managed.

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 documented procedures for the cloud HSM service and ensure it describes
a clear mandate for HSMs in use to be housed within a secure certified data centre
/ cloud region.

Review defined split of responsibilities and ensure that this has been agreed
between both (or all) parties.

Review the key and certificate management procedures and confirm they describe
the access controls to keys and certificates and how this is restricted only to be
accessible by the SM service provider.

Review defined of split of responsibilities and ensure that it defines that only the
SM service provider can access and manage cryptographic keys.

Review key storage locations and confirm that keys are only accessible by the SM
service provider. Confirm that any keys and certificates held outside of the HSM
are wrapped under a storage key accessible only to the SM service provider and
secured within the HSM.
Review the key and certificate management procedures and confirm they describe
the secure remote access connectivity to the HSMs which can only be from a
certified environment in accodance with 6.4.1 and 10.4.

Review HSM and remote access configurations to confirm that connectivity to the
HSM for key management activities is from a secure and certified environment in
accordance with 6.4.1 and 10.4.

Review the remote connection configuration to verify that a point-to-point secure

channel is implemented from the SM service provider's key management system
to the HSM and the channel provides confidentiality, integrity, authenticity, replay
protection and forward secrecy.

Review key and certificate management documentation to verify that remote

management access is restricted to trusted sources and authorised personnel
only in line with 6.2.2 for applicable dual-control requirements and 6.4.1, 10.4.2,
10.4.5 and 10.4.7 for applicable requirements.

Review remote access configuration settings to observe that access is restricted to

trusted sources and authorised personnel only and verify configurations are
aligned with in line with 6.2.2 for applicable dual-control requirements and 6.4.1,
10.4.2, 10.4.5 and 10.4.7 for applicable requirements.

Observe authorised access attempts to validated that access is restricted

accordingly and aligned to 6.2.2 for applicable dual-control requirements and
6.4.1, 10.4.2, 10.4.5 and 10.4.7 for applicable requirements.

Review HSMs in use and confirm that all partitions, if supported, are allocated to a
single SM service provider.
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.

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

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.
Evaluation of the risk assessment by the audit team will consider the risks related
to the audit site and to the overall eUICC eco-system. Where an auditee has
assessed the risks of remote access as acceptable at an internal business level, this
may not always be accepted for certification if the auditors consider that the risks
to the overall eco-system are not adequately addressed.
Where remote access is provided, this should be limited to support from known
and trusted personnel within specialist or dedicated teams for remote support or
maintenance of key systems (e.g. dedicated firewall management or production
platform teams).
Where third party-remote access is required for support and involves remote
access to environments containing networks, systems or data within the scope of
SAS certification it is expected that this would be declared prior to the audit. The
third party will normally be subject to an SAS audit on the basis of being a
supporting site/organisation – see section 10.4.6 for more details.

Observe the remote access mechanism and connections to confirm that the
secure channel is from the remote user's device to the target environment.

Review the secure channel configuration for strong encryption and same level of
access control as local access to target devices.

Technical controls in place at the site to restrict the level of access for remote
users should be demonstrated at the audit. The auditors will expect to see
evidence that these controls are implemented at, and managed from a site whose
activities are SAS certified.
Technical controls in place at the site to restrict the level of access for remote
users should be demonstrated at the audit. The auditors will expect to see
evidence that these controls are implemented at, and managed from a site whose
activities are SAS certified.
Control of the pre-defined services exposed to remote users should be
demonstrated at the audit. The auditors will expect to see evidence that services
are designed, implemented and executed in a way that:
• Limits the scope to clearly defined roles.
• Restricts any visibility of sensitive information.
Examples of sensitive information include:
• Class 1 or class 2 data related to the SAS-certified activities.
• Information about system or security configuration that could be of use to a
potential attacker e.g. firewall rules.

This level of access carries the highest level of risk. By default, certified sites that
permit this level of inbound access are expected to demonstrate that these
activities are carried out from within an environment where the logical and
physical security controls and associated processes comply with the requirements
of SAS. In most cases this will require the site hosting the endpoint(s) to be subject
to an SAS audit from the relevant scheme (UP or SM) as part of the certification
process.
Where remote management is provided through an administration portal or tool
that permits administrative actions but no direct access to the system; the portal
or tool itself may also fall within the scope of the audit (e.g. portal/tool audit logs,
evidence of patch management, penetration testing against portal/tool).
SAS does allow for exceptions to the above to be considered in specific
circumstances, as described in 10.4.6.
If a system is presented as off-line / air-gapped for the purpose of the SAS certified
The risk assessment should be presented prior to implementation either:
activities then no level of remote access would be expected.
• At an SAS-SM audit.
Or
• Via a major change notification to the GSMA (in accordance with the SAS-SM
Methodology) for projects that do not align with the site’s audit schedule.
Remote access permitted under the exception should be temporary (during
authorised and controlled periods only), with each access monitored from a SAS-
SM site. The access should be restricted in scope and controlled from the SAS-SM
environment - typically via session monitoring - with no data exporting capabilities
and virtual escorting (ability for an operator in the SAS-SM environment to
monitor the remote session in real-time and terminate it if needed). The
procedure describing this type of remote access must be documented and
demonstrated during the audit.
Workstations used to remotely connect to secure environment should be
reviewed to ensure individuals are authenticated prior to accessing the device,
should be approved company devices, up-to-date with latest relevant patches and
should be hardened as per a defined policy.

Remote access configuration should be reviewed to ensure that it is only possible

from designated devices, on designated networks and from a certified physical
location assessed under the SAS-SM scheme.

The configuration of the remote access should be reviewed for integrity

protection of the remote access configuration., with notifications / alerts for
changes to be verified.

The secure channel configuration should be reviewed between the dedicated

endpoint network(s) to the secure HSA network, ensuring mutual authentication
and confidentiality is established.

VPN configuration should be observed to be implemented in line with security

best practices with encryption keys and authentication credentials securely
generated, stored and exchanged.
The secure channel configuration should be reviewed ensuring that the
connection terminates on a dedicated system and network used for the remote
connectivity.

Inbound connections should be review to ensure that only the secure channel can
be used for all connectivity.

Review of network architecture diagrams and network device configurations

should verify that one or more firewalls protect the target network and jump
hosts are used within the DMZ and backend HSA networks.

There should be no direct remote connections to target systems in the HSA

environment.

The remote access process should be reviewed, along with defined policies and
configurations, to verify that MFA is implemented for all remote connections to
higher security networks and from offsite locations.

Audit trails should be reviewed to show all remote activity is being logged and is
linked to an individual.

Audit log integrity mechanisms should be reviewed to prevent modification,

deletion or disabling of the logs.

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 of 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.

For a sample of software developed and released into the environment confirm
that peer code review is performed and formal approval is recorded from relevant
management individuals prior to release.

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).

For a sample of software developed and released into the environment confirm
that peer code review is performed and formal approval is recorded from relevant
management individuals prior to release.
Review documented procedures to confirm that it defines how customer
environments are segregated and how customers can only have access rights
within their designated environments.

Confirm that customers are provided with access rights to their own environments
only.

Customers running their own applications should be reviewed to ensure that

customers use their own unique ID, and not privileged user IDs.

For example, on shared web server's shared IDs shall not be used.

Review documented procedures clearly define the protection controls preventing

customer's monopolising shared system resources.

Observe implemented controls and confirm customer SLAs are being met and
customer's cannot override and monopolise shared system resources.
Review procedures for data replication and backup to confirm that controls are
fully defined preventing the replication or backup of data from certified SAS-SM
locations to non-certified SAS-SM locations.

Controls should be reviewed to confirm that data is not being replicated to non-
certified locations as per defined methodology.
 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
• 3 Party management policy
rd
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, 2.4.2
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.7

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
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
Document Title
File Reference