Cloud Security Compliance: FedRAMP, HIPAA and ISO 27017 Guide
Cloud security compliance means demonstrating adherence to binding regimes like FedRAMP, HIPAA or ISO 27017, not just aligning with a voluntary standard. If you passed a compliance audit last year and still had a data exposure months later, that gap traces back to one specific misunderstanding this guide exists to close.
What Does “Cloud Security Compliance” Mean, and How Is It Different From a Security Standard?
Standards, NIST CSF, CSA CCM, NCSC’s principles, are voluntary reference points organizations choose to align with. Compliance regimes carry binding legal, contractual or market access consequences for non-adherence, whether that is a regulatory fine, exclusion from a market, or a lost client relationship requiring proof of certification.
| Criteria | Standards | Compliance Regimes |
| Voluntary or binding | Voluntary | Binding |
| Consequence of non-adherence | Weaker security posture | Fine, market exclusion, lost contract |
| Formally audited | Optional | Usually required |
| Related post | Cloud Security Frameworks | This guide |
Here is the actual test worth applying, since the two words get used interchangeably constantly. Does not adhering to this thing carry a binding consequence, a fine, market exclusion, a lost contract? If yes, it is compliance. If the consequence is a less structured security posture, it is a standard.
ISO 27017 sits in both categories at once, worth flagging immediately. The underlying ISO 27001 and 27017 controls function as a voluntary standard an organization can informally align with. Pursuing formal, audited certification converts that same standard into a demonstrable compliance credential, the specific process this post addresses.
Knowing what a standard contains and knowing how to actually achieve, evidence and maintain compliance against a binding regime are genuinely different bodies of work. The second is considerably more operationally demanding, exactly what this guide covers that a standards overview cannot.
What Is FedRAMP, and Who Actually Needs to Pursue It?
The Federal Risk and Authorization Management Program, FedRAMP, is a US government programme standardizing security assessment, authorization and continuous monitoring for cloud products and services used by federal agencies.
Here is the distinction most organizations get wrong. FedRAMP authorisation is pursued almost exclusively by cloud service providers wanting to sell to the federal government, not by the vast majority of businesses reading a guide like this. Most readers will encounter FedRAMP as consumers of an authorized service rather than as the party seeking authorization.
You only need to pursue FedRAMP authorization directly if you are a cloud service provider marketing a product specifically to federal agencies. FedRAMP has three impact levels, Low, Moderate and High, under FIPS 199, based on the potential impact of a breach. The FedRAMP Marketplace is the public registry of authorized services at each level.
How Does the FedRAMP Authorization Process Work?
For CSPs genuinely pursuing authorization, the process involves a security assessment against the applicable NIST SP 800-53 control baseline, conducted by an accredited Third Party Assessment Organization, followed by agency sponsored or broader authorization.
Continuous monitoring is an ongoing obligation, not a one time achievement. Authorized CSPs must maintain continuous monitoring and regular reassessment, meaning FedRAMP authorization is a sustained commitment rather than a certificate earned once and filed away.
For the far more common reader, consuming rather than pursuing, the practical task is verifying a service’s current listing and impact level on the Marketplace, and separately obtaining your own system’s Authorization to Operate if you are a federal agency or contractor, following the NIST SP 800-37 Risk Management Framework.
What Does HIPAA Require Specifically for Cloud-Hosted PHI?
HIPAA compliance in the cloud requires a Business Associate Agreement covering the specific service storing or processing PHI, not just a general agreement with the provider. It also requires encryption at rest and in transit, cloud native audit logging, and access controls scoped to PHI containing resources specifically.
Here is the gap that catches organizations out constantly. BAA eligibility varies by specific service, not by provider as a whole. AWS, Microsoft Azure and Google Cloud each offer BAAs covering eligible services, but not every service in a provider’s catalogue is HIPAA eligible. An organization can hold a valid, signed BAA while still using a specific, non covered service to store or process PHI, in violation of the same agreement they believed protected them.
Cloud specific technical safeguards worth naming directly: encryption of PHI at rest and in transit, cloud native audit logging, AWS CloudTrail, Azure Monitor, Google Cloud Audit Logs, covering access to PHI containing resources, and access controls restricting those resources specifically rather than relying on organization wide default permissions.
The HHS Office for Civil Rights has published guidance addressing cloud computing environments directly, a valuable, authoritative reference point for cloud specific HIPAA questions.
How Do You Pursue ISO 27017 Certification?
ISO 27017 certification is pursued as an extension to ISO 27001 certification of an organization’s Information Security Management System, typically pursued concurrently rather than in isolation.
Unlike FedRAMP, predominantly CSP side, and HIPAA, a legal obligation on covered entities, ISO 27017 can be pursued either by a cloud service provider certifying their own platform, or by a customer organization certifying their own ISMS. That makes it the most broadly applicable of the three regimes here.
The practical process: gap analysis against the ISO 27001 and 27017 control sets, updating the Statement of Applicability, implementing identified gaps, an internal audit, then a two stage external audit by an accredited certification body. Ongoing maintenance means annual surveillance audits and a full recertification audit roughly every three years. Choosing a body accredited by a recognized national accreditation body, UKAS in the UK, ensures the certification carries genuine, internationally recognized weight.
Why Doesn’t Using a Compliant Cloud Provider Automatically Make You Compliant?
No. A provider’s authorization or certification covers its own infrastructure, never the customer’s configuration, access management or data handling on top of it. A FedRAMP platform still needs the customer’s own ATO. A BAA does not itself enable encryption. A provider’s ISO 27017 certification says nothing about the customer’s own ISMS.
This section delivers the central argument running through this guide, applying the shared responsibility principle to each of the three regimes above, concretely.
The FedRAMP illustration: an organization using a FedRAMP authorized platform still must obtain its own system’s Authorization to Operate through the NIST Risk Management Framework. The platform’s authorization covers the infrastructure beneath it, not the customer’s own application and configuration built on top.
The HIPAA illustration: a fully executed BAA establishes that the provider will handle PHI appropriately, but does not itself enable encryption, restrict access appropriately, or classify what data actually constitutes PHI. Those remain entirely customer side actions a signed BAA does not perform automatically.
The ISO 27017 illustration: a provider’s own certification says nothing about whether the customer’s own configuration and access management within that platform meets the same standard. A customer wanting an equivalent claim needs its own separate, potentially certified, ISMS.
This exact provider certified but customer unconfigured gap is what Cyber Security Solutions Ltd finds most often in a compliance gap assessment. The pattern repeats identically across all three regimes because each is, at its core, the same shared responsibility boundary. Treating a provider’s compliance status as automatically covering your own use is the exact misunderstanding that causes most cloud security failures.
FedRAMP vs HIPAA vs ISO 27017: Who Needs Which, and Can You Need More Than One?
FedRAMP applies to organizations selling cloud services to US federal agencies, or federal agencies and contractors selecting and using cloud services.
| Regime | Applies To | Who Pursues It | Mandatory/Voluntary | Renewal Cycle |
| FedRAMP | Federal agencies, contractors, CSPs selling to government | CSPs (authorization), agencies (ATO) | Mandatory for federal use | Continuous monitoring |
| HIPAA | US covered entities and business associates handling PHI | Healthcare organizations, business associates | Mandatory (legal) | Ongoing safeguard maintenance |
| ISO 27017 | Any organization, sector or geography | Providers or customer organizations | Voluntary | Annual surveillance, 3-year recertification |
HIPAA applies to covered entities and business associates in the US handling electronic protected health information, a legal obligation rather than a choice. ISO 27017 applies to any organization, sector or geography wanting to demonstrate cloud specific information security maturity, the most broadly applicable of the three.
Overlap across multiple regimes simultaneously is common, not exceptional. A US healthcare organization handling PHI in the cloud is subject to HIPAA regardless of any other certification, and may separately pursue ISO 27017 as a commercial differentiator. A healthcare adjacent federal contractor could need HIPAA compliance, FedRAMP authorized infrastructure and ISO 27017 certification simultaneously, each addressing a distinct audience.
What Other Compliance Regimes Commonly Come Up Alongside These Three?
SOC 2 is a widely requested attestation in vendor risk assessments for SaaS and cloud providers, distinct from ISO 27017 in format, an auditor’s report rather than a certification, though addressing overlapping control areas.
PCI DSS is relevant specifically where payment card data moves through cloud infrastructure, a distinct regime with its own cloud specific guidance. GDPR and UK GDPR govern personal data processing in the cloud generally, covered elsewhere in this series.
Healthcare organizations should also see our dedicated guide to cloud security for healthcare, and financial services organizations our guide to cloud security for financial services. Individual professional certifications like CCSP and CCSK are a distinct concept from the organizational compliance covered here. Naming these regimes prevents you from assuming FedRAMP, HIPAA and ISO 27017 represent the complete universe of relevant obligations.
How Do You Build a Cloud Compliance Programme Step by Step?
Building a compliance programme starts with identifying which regimes genuinely apply, then addressing FedRAMP, HIPAA and ISO 27017 specifics individually, documenting exactly which obligations transfer to your provider, using DSPM to confirm where regulated data resides, building continuous monitoring into ongoing operations, and revisiting scope as the business changes.
- Identify which regimes genuinely apply based on sector, geography, customer base and data types handled.
- For FedRAMP specifically, determine whether you are a CSP needing authorization or a consumer needing to select an already authorized service and pursue your own ATO.
- For HIPAA, confirm BAA coverage extends specifically to every cloud service actually storing or processing PHI.
- For ISO 27017, conduct a gap analysis against the ISO 27001 and 27017 control set before committing to a certification timeline.
- Document, for each applicable regime, exactly which obligations transfer to your cloud provider and which remain yours.
- Use DSPM to confirm exactly where regulated data actually resides across your cloud estate.
- Build continuous monitoring and periodic reassessment into ongoing operations rather than treating any regime as a one time achievement.
- Revisit applicability whenever your organization adopts a new cloud service, enters a new market or takes on a new client relationship.
Conclusion
Cloud security compliance is not something your provider hands you along with the invoice. FedRAMP, HIPAA and ISO 27017 each work the same way. The provider covers its infrastructure. You cover everything you built and configured on top of it. To find out exactly where your own compliance gaps sit across the regimes that apply to you, visit cybersecuritysolutionsltd.com for a free compliance gap assessment from Cyber Security Solutions Ltd.
FAQs
No. The provider’s authorization covers its own infrastructure, not your application, configuration or data handling built on top of it. If you are a federal agency or contractor, you still need your own system’s Authorization to Operate under the NIST Risk Management Framework.
Not on its own. BAA coverage is specific to individual services, not the provider as a whole. You can hold a valid BAA while using a non covered service to store PHI, violating that agreement. Encryption, access controls and audit logging remain your responsibility regardless.
Effectively, yes. ISO 27017 certification extends ISO 27001 certification of your Information Security Management System, and the two are typically pursued concurrently rather than 27017 in isolation. There is no standalone path to 27017 certification without an underlying certified ISMS.
Rarely directly. FedRAMP authorization is pursued almost exclusively by cloud service providers selling to federal agencies. Most businesses, including most federal contractors, only need to select an already authorised service from the FedRAMP Marketplace and pursue their own system’s ATO.
Yes, and it is common, not exceptional. A healthcare adjacent federal contractor handling patient data could need HIPAA compliance as a legal obligation, FedRAMP authorized infrastructure to serve federal clients, and ISO 27017 certification as a commercial differentiator, all simultaneously.
A standard is a voluntary reference point, like NIST CSF, organizations choose to align with for structure and benchmarking. A compliance regime carries binding legal, contractual or market access consequences for non-adherence, a regulatory fine, exclusion from a market, or a lost client relationship.
