Dimension data pursuing compliance in public cloud white paper

Pursuing Compliance in the Public Cloud
Identifying the right compliance strategy for your business in the cloud

February 2014
Version 1.1
Jason Cumberland

Dimension Data White Paper: Compliance in the Public Cloud

Introduction:
Organisations considering moving IT assets or applications from an on-premise installation to the
cloud face a bewildering array of compliance options and certifications. Organisations commonly ask
themselves these questions when developing their own compliance roadmap and strategy:
•
•
•
•
•

Which certifications do I need to achieve directly?
For which certifications can I leverage my data centre provider?
Do I need to bring in an outside auditor or can I conduct a self-audit?
What are my competitors doing in terms of compliance? Should my strategy be the same?
What will my clients expect of me in the sales process?

The key to successfully navigating the compliance waters is to determine which of the many available
certifications are relevant to your business and which add more cost and complexity to your business
than they’re worth. Given that each of the common compliance standards is accompanied by
significant costs, correctly identifying the requirements from your internal stakeholders and
clients is a critical initial step when developing your compliance strategy.
In this paper, we’ll discuss several of the most common compliance standards to help determine the
applicability of each to your business. These include:
•
•
•
•
•
•
•
•
•
•

AICPA Statement on Standards for Attestation Engagements No. 16 (SSAE 16)
Payment Card Industry Data Security Standard (PCI DSS)
The Health Insurance Portability and Accountability Act of 1996 (HIPAA)
US–EU Safe Harbor Framework
International Standards Organization (ISO) 17799 / 27002
International Standards Organization (ISO) 27001
Food and Drug Administration (FDA) Title 21, Code of Federal Regulations (CFR) Part 11
Federal Information Processing Standards (FIPS) / Federal Information Security Management
Act (FISMA) / The Federal Risk and Authorization Management Program (FedRAMP)
Sarbanes–Oxley Act (SOX)
Gramm–Leach–Bliley Act (GLBA)

Page 2 of 16


Commonly used terminology
To aid in the detailed evaluation of each of the above certifications, it’s important to establish the
terminology that we’ll use throughout this paper.

Control objectives versus control procedures and activities
Control objectives provide high-level goals that organisations try to achieve using policies, procedures,
and systems. Control procedures and activities are the actual policies and procedures that are put in
place to achieve the objectives.

Best practice versus prescriptive standards
‘Best practice’ standards define control objectives, goals or methods that work across many
organisations but allow organisations to choose which ones to use and how to implement them.
‘Prescriptive’ standards provide detailed control requirements that need to be met exactly as outlined
in order to meet the standard.

Attestation versus certification
Attestation is the result of an audit conducted to measure compliance with control objectives set by
an organisation. The auditor measures whether the control objectives are met by the control
procedures in place. The auditor attests to the organisation’s ability to meet its own standards but
does not determine whether the standards are valid. In this case, because there are no prescriptive
standards, there’s no easy way to compare organisations simply by establishing whether an
attestation standard has been completed.
Certification is the result of an audit conducted to measure compliance with prescriptive standards.
The auditor can explicitly certify whether those standards have been met. From a buyer’s perspective,
these standards can be used to directly compare service providers given that the standards for each
organisation are the same.

Page 3 of 16


Detailed review of compliance and common security standards
SSAE 16 (Formerly SAS70)
The Statement on Standards for Attestation Engagements (SSAE) 16 is an attestation standard used
by auditors to evaluate the internal systems of a service provider. ‘Systems’ are generally defined as
the services provided, along with the supporting processes, policies, procedures, personnel and
operational activities that constitute the service organisation's core activities that are relevant to user
entities.

SSAE 16 is not a prescriptive standard. Instead, it reviews whether an organisation’s control
procedures are followed and whether those procedures achieve the organisation’s control objectives.
The audit does not make a judgment as to whether the control objectives are ‘good’ or will meet
security or other objectives. However, companies are now required to submit a management
assertion as part of the SSAE process attesting (among other items) that the control objectives were
suitably designed, and that the description of the system is accurate.
SSAE 16 control objective example: An organisation could define an SSAE 16 control objective
that stipulates only individuals with a green identity badge are allowed access to the data centre,
and a control activity that the posted security guard will allow anyone into the data centre as long
as their identity badge meets this criterion. In this case, as part of the SSAE 16 review, outside
auditors will evaluate whether the control activity (the security guard’s ability to enforce the control
objective) is sufficient to meet the control objective, and ask for proof (documentation) that the
control activity was consistently followed. So long as this documentation exists, this control
objective will be achieved.
While this is a ‘bad’ control objective from a security point of a view, as long as an organisation shows
that it meets the stated objective, it will be considered to be compliant from an SSAE 16 point of view.
There are two types of SSAE 16 audits, usually performed sequentially:
• SSAE 16 Type I – Type 1 is a “point in time” audit that evaluates the control procedures at a
single point in time, identifying whether the control procedures will meet the control
objectives.
• SSAE 16 Type II – Type II evaluates the effectiveness of control procedures over a period of
time, so the auditor looks to make sure the control procedures are being followed.
The result of a completed SSAE 16 audit is a SOC 1 (service organisation control) report.
Prevalence and relevance:
From a service provider perspective, the SSAE 16 Type II audit is generally considered ‘table stakes’
in the world of service providers of public cloud, managed hosting, and co-location services. It should
be a must-have for any commercial application hosting. The standard is most common in North
America, with acceptance among many global organisations as well.
While the controls and scope of an SSAE audit vary greatly for the reasons explained above,
generally, there are three broad areas of scope for an SSAE audit:
Page 4 of 16


•
•
•

Software development control objectives
Operational control objectives
Data centre/facility control objectives

In the best case, a service provider can cover only two of these three, given that it has no involvement
in a client’s software development process. If a client manages its own environment (software
deployment, change control, patching procedures, etc.) – which is typical – then the provider’s
operational controls are of limited value to a prospective client in a sales cycle given that the
independent software vendor (ISV) will be responsible for managing its own operational controls. In
this case, relying on a provider’s SSAE audit covers only one of three areas of scope of the SSAE
audit.
Service providers offering managed services that extend the management of the client’s application
(i.e. Application Operations from Dimension Data) extend coverage to two of the three areas of scope,
which can offer prospective clients more assurance than if an ISV’s operational processes are
unaudited.
Service provider versus ISV/enterprise applicability:
While considered a must-have for service providers, the requirement for an independent software
vendor or enterprise to complete its own audit is far less definite. In some cases, ISVs can leverage
the SSAE certification of the data centre provider in its sales cycles to satisfy their clients’ control
requirements. However, sophisticated buyers of IT services or software-as-a-service (SaaS) offerings
will often insist on seeing the enterprise/ISV’s SSAE audit results as well.
Approximate costs:
The costs of any audit discussed in this paper include a combination of hard costs (money paid to an
outside firm to complete the audit, hardware and software costs to meet various security requirements,
etc.) as well as personnel costs related to the time required to prepare for the audit, implement the
required organisational controls, and work with the auditors throughout their review to ensure a
successful result. In many cases, the latter category of soft costs is far more expensive than the fees
paid to the auditors. These soft costs are also more difficult to generalise, as each organisation’s
experience will differ. Our advice is to work with your auditor to assess the time required before
beginning any outside audit process. This will ensure that internal expectations are properly
established to successfully complete the audit in the established timelines.
In general, the hard costs of an SSAE attestation paid to an outside firm range from USD 15,000 25,000 per site being inspected, with significant variation depending on the scope of audit. As
mentioned above, in the case of SSAE the organisational costs of SSAE compliance (including the
costs to prepare and gather documentation for the audit, employment of an internal security/control
officer, costs of ongoing internal audit activities throughout the year to maintain compliance, etc.)
easily outweigh the hard costs.
Best practices and recommendations:
When selling a service to a commercial or enterprise market (i.e. non-consumer services), SSAErelated questions will commonly come up in pre-sales conversations. If your organisation has the
Page 5 of 16

operational discipline to meet the control objectives you define (generally through a culture of strict
adherence to process, heavy documentation, and internal audit reinforcement), and you can justify the
costs of your own SSAE audit, our recommendation is that you pursue your own audit to remove
barriers in the pre-sales process. By selecting a service provider that has completed its own audit,
you can often limit the costs and scope of your own audit by ‘carving out’ the portions of the controls
already met by your service provider, and limit the scope of your own audit to only those items for
which your organisation is directly responsible.
Due to the costs of an SSAE audit as well as the maturity of organisational processes and controls
required, many smaller or early-stage organisations cannot justify the conducting their own SSAE
audit. In this case, organisations commonly utilise their service provider’s SSAE compliance
(generally at the facility level). Organisations can leverage more meaningful and extensive SSAE
compliance by selecting a vendor with a managed service offering that extends its SSAE compliance
through the operational controls related to the specific application being hosted. This allows the
ISV/enterprise to confidently respond to pre-sales questions regarding SSAE compliance covering
both facilities and operational controls, without incurring the significant costs of an individual SSAE
audit.
Lastly, regardless of whether you choose to pursue your own SSAE audit, ensure that you carefully
review your provider’s SSAE report (generally under a non-disclosure agreement). The details of
these tests will vary from one provider to another, and it is critical to your own risk mitigation strategy
to understand the scope and detailed results of each provider’s audit.

Payment Card Industry Data Security Standard (PCI DSS)
PCI DSS is a prescriptive data security standard that applies when storing, processing, or
transmitting credit and debit card data. The security standards are agreed to by the major credit
issuers (Visa, MasterCard, etc.) to eliminate the establishment of separate standards for each issuer.
All credit card companies require adherence to these standards in their terms of service.
‘Acquiring banks’ (banks processing the issuer’s credit card transactions) are responsible for ensuring
that their merchants are compliant with the PCI Data Security Standard and that the merchants use
PCI-certified service providers. Acquiring banks generally ‘pass through’ this requirement in their
agreement with their merchants, meaning that the merchants are financially responsible for any losses
if they are not compliant or were using non-compliant service providers.
There are currently four different levels of certification and related requirements*:
• Level 1 (> 6 million transactions per year, credit card processors/payment gateway):
o Requires an annual on-site audit and quarterly network scan
• Level 2 (> 1million credit/debit transactions per year):
o Requires an annual on-site audit and quarterly network scan or self-assessment
questionnaire (requirements vary depending on issuing bank)
• Level 3 (< 1million transactions per year):
o Requires an annual self-assessment questionnaire and quarterly network scan
• Level 4 (20k – 1million transactions per year):
o Requires an annual self-assessment questionnaire and quarterly network scan
Page 6 of 16


*Note that each major card issuer has slightly varying requirements for Level 1 through 4. The
information above is a generalisation of the different issuers.
PCI is the compliance standard and the definitive standard for any organisation processing credit card
data.
Service provider vs. ISV/enterprise applicability:
Prospective buyers of SaaS or infrastructure-as-a-service (IaaS) often include PCI compliance in their
checklist of requirements without a complete understanding of the complexities involved in pursuing a
PCI compliance strategy. Similar to SSAE 16, PCI compliance can be achieved with varying audit
scopes. For a complete PCI compliance strategy, an organisation must be compliant at the hardware,
process, software, and facilities levels. A data centre provider’s PCI compliance cannot legitimately
cover all of these areas for a third-party hosting within their facilities (see best practices below for
further information).
Approximate costs:
Costs for a full-scale PCI audit vary significantly. The initial consulting fees to establish the scope of
the analysis and any gaps in current procedures commonly ranges from USD 25,000-100,000+
depending on the size of the organisation and established scope. A bare-bones onsite PCI audit
could cost as little as USD 20,000-30,000 per year, with in-depth audits for large organisations easily
costing more than USD 100,000 annually.
Key soft costs to consider:
The organisational process changes required to adhere to PCI compliance can be significant. Among
other things, organisations must nominate (or hire) an internal security officer who will be responsible
for managing compliance internally between audit periods.
The first distinction that we recommend clients make when pursuing PCI-compliant hosting is to
decide whether they are pursuing a PCI-compliant provider solely for marketing value (i.e. making the
claim that the application is hosted in PCI-compliant facilities), or whether the organisation actually
intends to pursue its own PCI audit of the application being hosted.
While we do not generally dispute the marketing value of the former strategy, from a security
perspective, this is not a model that will carry significant value with an experienced INFOSEC
organisation. If your application is processing or storing any credit card data, to be compliant with the
card issuer’s terms of service, your organisation must complete its own PCI audit. Similar to SSAE,
portions of the PCI requirements can be ‘carved out’ of your own audit based on your service provider
having completed a separate audit, but the application itself must undergo its own evaluation.

Health Insurance Portability and Accountability Act (HIPAA)
The sections of HIPAA relevant to data centre service providers relate to the security of patient data
processed or stored by ‘covered entities’. Covered entities include those with a direct patient
Page 7 of 16

relationship, such as hospitals, doctors, pharmacies and insurance companies. These entities must be
HIPAA compliant under the provisions of the law.
This definition of ‘covered entities’ makes it technically impossible for any data centre service
provider to be HIPAA compliant because they are not covered entities under the law’s provisions.
For this reason, we advise that organisations seeking data centre providers proceed with caution
when dealing with a service provider claiming HIPAA compliance.
While service providers cannot be HIPAA compliant, they may qualify as a ‘business associate’ of a
HIPAA-covered entity if involved in a function or activity involving the use or disclosure of protected
health information. Generally this means that if any patient data is stored in the application
running in a service provider’s infrastructure, a service provider is obligated as a business
associate under HIPAA.
HIPAA is a common compliance standard (though often misunderstood) and the definitive standard for
any organisation processing patient healthcare data.
HIPAA-covered medical organisations are required to contractually obligate business associates to
utilise security mechanisms and privacy procedures that include (but are not limited to):
• Security mechanisms that ensure all transmissions of data are authorised and employ the
standards necessary to protect the integrity and confidentiality of the data that is transmitted.
• Privacy procedures that require any unauthorised use or disclosure of protected health
information to be reported to the medical organisation.
• Security mechanisms that protect records and other data from improper access.
• Privacy policies that bind the service provider’s agents and subcontractors to the same
restrictions on the use and disclosure of protected health information as those imposed upon
the service provider.
In addition, the covered entity’s business associate agreement (BAA) with the service provider must
include specific procedures for the storage and transfer of patient data in the event that the contract is
terminated, the service provider goes out of business, and/or is acquired by or merged into an
organisation that is unsatisfactory to the entity.
Approximate costs:
While there are several organisations available to help you develop your HIPAA compliance strategy,
there is no third-party data centre audit requirement under HIPAA, so there’s no formal attestation or
certification that service providers can achieve. As a result, costs here are less definitive but may
include items such as backup software, data archiving tools, write-once storage media, etc. A service
provider experienced with HIPAA hosting will be able to provide for many of these requirements within
its standard offering.
Given the structure outlined above, the key distinction when seeking out service providers to host
HIPAA-related data is that they are willing to accept liability for breach of the confidentiality of the data
Page 8 of 16

they’re hosting. This is key to fulfilling an organisation’s responsibilities under HIPAA and ensures that
the risk for data confidentiality flows through to all organisations involved in the processing or storage
of the related data.
While there are general requirements for HIPAA hosting, there is not one standard set of contract or
security terms related to HIPAA, so expect some discussion with your provider regarding your specific
BAA and the best way to meet the requirements under its specific business associate agreement.

US–EU Safe Harbor
European Union (EU) law prohibits the transfer of an individual’s personal data to non-EU nations that
do not meet the European adequacy standard for privacy protection. To provide a streamlined means
for US organisations to comply with the law, the United States Commerce Department developed the
Safe Harbor framework of prescriptive security standards.
Safe Harbor certification will assure EU that your company provides ‘adequate’ privacy protection.
Safe Harbor requires you put in place a privacy policy and procedure that covers the gathering and
use of personal information. At a high level, the policy needs to cover several areas:
• Notice – you must provide notification about the purpose for which you collect and use
information about individuals, and explain disclosures to third parties. You also have to
provide individuals with a way to contact the company with inquiries or complaints.
• Choice – you must give individuals the ability to opt out of having their personal information
disclosed to a third party.
• Third parties – any third parties to which you disclose information must follow the same
policies.
• Access – you must give individuals the ability to correct, amend, or delete collected
information if it is inaccurate.
• Security – you must take reasonable precautions to protect the data.
• Data integrity – you must have a relevant purpose for maintaining and using any personal
data collected.
• Enforcement – you must implement systems to enforce these policies and fix any problems
identified.
This standard generally applies to enterprises, ISVs, and data centre providers. It’s uncommon for
organisations to rely completely on their data centre provider for this certification.
Approximate costs:
Safe Harbor is a self-audit certification. Certification consists primarily of developing a qualifying
privacy policy (for which you may wish to engage outside expertise) and identifying a company officer
who will certify that the organisation will follow the policy and Safe Harbor requirements. You must
also identify all data you are collecting about EU citizens. This information must be submitted to the
Commerce Department for review, after which the US Government will certify you under Safe Harbor.
There are no audit or application costs for achieving this certification.

Page 9 of 16

It’s our recommendation that clients dealing with European organisations pursue their own Safe
Harbor certification in addition to ensuring that their data centres are compliant.

International Standards Organization 17799 / 27002
ISO 17799 was renamed to ISO 27002 but references to both are still regularly found.
ISO 17799 provides best practice recommendations for information security management, covering all
information (files, paper, faxes, phone calls, email, etc.) within an organisation. These
recommendations may not all apply and do not all need to be used. Organisations are expected to
review and decide what is relevant for their specific use case.
The standard includes 134 specific controls, categorised into approximately 36 control objectives
covering areas such as:
1. Risk assessments and treatment
2. System policy
3. Organising information security
4. Asset management
5. Human resources security
6. Physical and environmental security
7. Communications and operations management
8. Access control
9. Information systems acquisition, development and maintenance
10. Information security incident management
11. Business continuity management
12. Compliance
Information security is defined within the standard in the context of three areas
– Confidentiality: ensuring that information is accessible only to those authorised to have
access.
– Integrity: safeguarding the accuracy and completeness of information and processing
methods.
– Availability: ensuring that authorised users have access to information when required.
Like the other ISO standards, this is most commonly pursued by global organisations.
Due to the self-audit nature of this standard, organisations serving a global market but without the
budget or desire to pursue ISO 27001 certification may prefer to adhere to this standard, or portions of
this standard, as an interim step.

International Standards Organization: ISO 27001
ISO 27001 provides a prescriptive specification for an organisation’s information security
management system (ISMS), which includes all of the policies, procedures, roles, responsibilities,

Page 10 of 16

resources, and structures that are used to protect an organisation's information, as well as the
management and control of the security risks associated with the information.
ISO 27001 is based on ISO 17799 / ISO 270002. However, unlike ISO 27002, ISO 27001 is a
standard an organisation can be certified against.
The audit is normally conducted in two stages:
• A review of the existence and completeness of key documentation such as the organisation's
security policy, statement of applicability (SoA) and risk treatment plan (RTP).
• An actual audit to test the existence and effectiveness of the ISMS controls stated in the SoA
and RTP, as well as their supporting documentation.
The various ISO certifications are generally preferred by organisations with operations outside North
America (in contrast to SSAE, which is more commonly accepted or preferred by organisations within
North America).
Similar to SSAE 16, this is an audit that can be valid for both service providers and enterprises. Due
to the costs of this audit, however, it is not commonly pursued by small or mid-market organisations,
particularly those organisations without global operations.
Approximate costs:
Estimated hard costs: These vary widely based on the size of the organisation and auditing firm, but
generally run between USD 50,000-100,000 with certifications valid for up to three years. Years two
and three each require a smaller scale, follow-up audit that generally costs an additional USD 5,00010,000.
Key soft costs to consider:
Due to the prescriptive and detailed nature of this certification, the soft costs of implementation can be
significant. These costs come chiefly from establishing policy documents, changing existing
operational process to comply with ISO standards, and the internal controls that must be implemented
to ensure compliance with the standards between the formal external audit periods.
For organisations dealing primarily with North American customers, an ISO certification may not be as
cost-effective or important as completing a well-scoped, in-depth SSAE audit. Due to the nonprescriptive nature of SSAE, that audit can actually be developed to meet many or all of the same
standards as ISO. While this strategy will not allow you to claim official ISO compliance, it will allow
you to provide prospective clients with an SSAE attestation and report showing the specific areas that
were audited, which will suffice in many situations. For organisations dealing primarily with clients
outside of North America, ISO certification is a requirement you will want to seriously consider.
Other less commonly cited certifications in the managed hosting / cloud service provider industry
include ISO 9001 (covering product quality management systems), ISO 14001 (also covering product
quality management systems, but those directly related to how a product is produced), ISO 50001
Page 11 of 16

(covering energy management systems), and OHSAS 18001 (standards for occupational health and
safety management systems).

FDA Title 21, CFR Part 11
This FDA regulation applies to all entities regulated by the FDA except food manufacturers. Common
examples are drug manufacturers, medical device manufacturers and biotechnology companies. This
regulation requires such companies to implement various controls, audits, validation systems and
documentation for software and systems related to electronic records and signatures maintained by
the organisations under FDA regulation.
These tend to be records or signatures that are being submitted to the FDA or stored as part of an
approval process for a new product
At a high level, the requirements include:
• Systems validation – all computer systems have to be ‘validated’. Essentially, the company
must identify and document what the system will be used for and who will use it, and ensure
that the hardware and software are adequate for the task (all verified through production
testing).
• Record retention – will vary depending on the FDA regulation to which the records are
related.
• Records security – securing data so only authorised users have access.
• Audit trails – maintenance of audit trails for the creation, modification, and deletion of
records, including who made the change and when.
• Electronic signatures – includes fingerprints, retinal scans, or ID names and passwords that
meet certain requirements. Signatures must include certain data (commonly the name of
person, whether the signature is providing an approval or denial, and a date and time). They
must also be protected so they cannot be modified once captured.
It is uncommon and improbable that service providers will need to meet this requirement directly.
Usually, the organisations outlined above are responsible for meeting these standards. A data centre
provider’s responsibility typically involves providing supporting hardware and tools such as write once,
read many (WORM) storage infrastructure.
Given that this is an enterprise-only requirement, the service provider can provide only limited
assistance in helping you maintain compliance with this regulation. As such, we recommend that you
ensure your cloud provider has dealt with these requirements before and can recommend
technologies to meet your specific FDA requirements.

FIPS, FISMA, and FedRAMP
FIPS are Federal Information Processing Standards, many of which are incorporated into FISMA, the
Federal Information Security Management Act (2002). The act requires all federal agencies and their
contractors to safeguard their electronic systems (regardless of whether these agencies or systems
involve cloud providers).
Page 12 of 16


FedRAMP is the Federal Risk and Authorization Management Program (2012). It requires that all
federal organisations that use or plan to use a cloud environment implement the security controls of
this program. FedRAMP contains additional controls, not present in a FISMA assessment, specific to
cloud environments.
FedRAMP was created to establish a risk management programme that could be applied to the entire
federal government. At a high level, it covers four steps before establishing a cloud-based service:
•

Initiating: agencies or cloud service providers (CSPs) initiate the FedRAMP programme by
pursuing a security authorisation.

•

Assessing: based on the NIST SP 800-53 Rev. 3 requirements, CSPs must hire a third-party
assessment organisation to perform an independent assessment.

•

Authorising: upon completion, the security assessment package will then be forwarded to the
FedRAMP Joint Authorization Board (otherwise known as JAB) for review.

•

Leveraging: the CSP will then continue to work with the executive departments and agencies
for authority to operate (ATO) permissions.

Because of the scope of these federal compliance standards, in general ISVs or enterprises must
obtain their own compliance as well as operate in a data centre that meets these standards.
Approximate costs:
Like other audits, FedRAMP costs vary, but range from USD 40,000-100,000. The soft costs are far
more significant, with the average assessment process requiring six months or more.
Companies whose government clients make up a large portion of their revenue will likely have no
choice but to pursue the FedRAMP certification process. As FedRAMP is still an emerging standard
as of the date of this paper, expect changes in the coming year as the government formalises the
programme. Due to the significant costs of compliance and limited relevancy outside government
agencies, non-government-centric organisations are not likely to pursue this standard.

Sarbanes–Oxley (SOX) Compliance
In 2002, the US Congress enacted the Sarbanes–Oxley (SOX) Act. The act was targeted at changing
the way public companies report their financial results and carried with it a significant impact to IT
organisations due to the heavy logging and documentation requirements included in the act. The act
also contains additional controls related to record retention, which must be carefully implemented into
any hosting strategy.
Section 404 of SOX covers the assessment of internal controls (to be conducted by an outside party).
COBIT stands for Control Objectives for Information and Related Technology. These objectives
require logging and reporting of key activities such as application level access control changes, events
Page 13 of 16

triggering access changes, transaction types, user IDs, and date and timestamps for all such activities.
All unauthorised attempts to access the application must also be logged and reported with a time and
IP address.
Due to the financial reporting focus of the SOX Act, data centre service providers cannot provide SOX
compliance for their clients. However, the internal controls of the service provider can make an
outside SOX audit far easier to complete successfully. In many cases, the controls from other, more
directly relevant IT standards such as SSAE 16 or ISO 27001 can also be used to help verify SOX
compliance. In addition, public cloud providers with user-based permissions, individual account
logins, and in-depth logging built into the application can make SOX compliance far easier.
Apart from the infrastructure controls in place, an ISV or enterprise must implement additional controls
at the server or application level to meet the requirements of SOX.

The GLBA was originally passed in 1999 and its implications were largely for financial institutions. In
the Act, financial institutions are defined as all businesses, regardless of size, that are ‘significantly
engaged’ in providing financial products or services. This includes, for example, cheque-cashing
businesses, payday lenders, mortgage brokers, non-bank lenders, personal property or real estate
appraisers, professional tax preparers, and courier services.
Two specific rules in the act are most directly relevant to conducting business in the cloud.
The Financial Privacy Rule, which governs the collection and disclosure of customers’ personal
financial information by financial institutions. It also applies to companies, regardless of whether they
are financial institutions, that receive such information – companies like cloud providers.
The Safeguards Rule requires all financial institutions to design, implement and maintain a
‘comprehensive information security programme’ to protect non-public customer information. It
requires period testing of the programme as well.
Lastly, prior to allowing a service provider to access customers’ personal information, the financial
institution must:
•
•

Take reasonable steps to select and retain service providers that are capable of maintaining
appropriate safeguards for the customer information.
Require the service providers, under contract, to implement and maintain such safeguards.

Cloud providers are included in the scope of the Financial Privacy Rule above. Prior to disclosing any
information to a cloud provider, cloud customers must enter into a contract with the provider which
prohibits the provider from disclosing or using the affected data in any manner other than to carry out
the purposes for which the information was disclosed. In practice, this is a common legal provision in
most cloud contracts.
Page 14 of 16


The GLBA also requires that all financial institutions provide their clients with the right to opt out of
sharing their personal financial information with non-affiliated third parties. In this case, the enterprise
must carefully develop provisions to remove specific client data from external storage systems as
soon as such a request is received.

For financial institutions considering storing data in a cloud environment: ensure that the internal
operational controls and security policies put in place to comply with GLBA can be extended into your
cloud environment. Not all cloud providers are equal when it comes to security within the
environment. Be sure to review the relevant details carefully to understand whether GLBA can be
maintained in the cloud environment of your choice. Clients with GLBA exposure may also want to
explore hosted private cloud alternatives where greater degrees of data separation can be achieved.
Lastly, ensure that you follow the stipulations above regarding the Privacy Rule and related
contractual requirements to maintain compliance with GLBA when working with a third-party cloud
provider.

Page 15 of 16


Dimension Data cloud compliance
Dimension Data operates numerous data centre facilities around the world, and as such, our
compliance audits and certifications vary by location. In combination, Dimension Data and/or the
facilities in which we operate our data centres meet the following compliance standards:
•
•
•
•
•
•
•
•

SSAE 16 Type II
PCI Level 1
FISMA Moderate
EU Safe Harbor
ISO 9001(2008)
ISO 27001(2005)
ISO 50001(2011)
OHSAS 18001(2007)

In addition, while Dimension Data or its facilities cannot be directly certified against the following
standards (given that data centre providers are not the focus of these standards), we regularly help
clients achieve and maintain their own compliance against these standards:
•
•
•
•

HIPAA
FDA Title 21, CFR Part 11
Sarbanes–Oxley (SOX)

Successfully complying with any of these standards typically involves a joint effort between the
Dimension Data team and our client. We have significant experience in operating under all of these
compliance standards and would welcome the opportunity to answer any questions you have about
maintaining these standards in a cloud environment.

Page 16 of 16

Dimension data pursuing compliance in public cloud white paper

More Related Content

What's hot

Similar to Dimension data pursuing compliance in public cloud white paper

Recently uploaded

Dimension data pursuing compliance in public cloud white paper