Most SaaS providers do not choose their compliance obligations: their customers hand them over, one contract, questionnaire and procurement rule at a time. An enterprise buyer asks for a SOC 2 Type 2 report, a European bank sends a DORA contract addendum, a hospital needs a business associate agreement, a US agency requires FedRAMP and a customer that builds connected products asks what the Cyber Resilience Act means for your SDK. This map is written from the provider's side: for each obligation it shows who asks for it, what triggers it, what you actually have to deliver and where one piece of evidence can serve several requests. Status as checked on 14 November 2026. It is for founders, heads of security, GRC leads and sales engineers at SaaS companies; the threat and control picture for SaaS companies is in the Cybersecurity for SaaS Companies Guide.
Key takeaways
- Customers are the regulator you meet first. SOC 2, ISO/IEC 27001, DORA Article 30 terms, GDPR Article 28 terms and HIPAA business associate agreements all reach a SaaS provider through a customer contract, not a regulator's letter.
- Some duties are now direct. NIS2 lists cloud computing service providers in Annex I, the UK Cyber Security and Resilience Bill would regulate medium and large managed service providers, and FedRAMP is the gate for selling cloud services to US federal agencies.
- The CRA is about what you ship, not what you host. Its obligations attach to products with digital elements, so installable agents, SDKs, desktop clients and device firmware are in scope while the hosted service itself is generally treated under NIS2.
- Dates are close. CRA vulnerability and incident reporting applies from 11 September 2026, full CRA application from 11 December 2027, and FedRAMP will stop accepting new Rev5 certifications on 11 June 2027.
- Build one control set, many outputs. A single ISMS with mapped controls, one incident process with the shortest clock built in, and a standard contract schedule answer most requests; bespoke answers per customer do not scale.
Regulations and frameworks at a glance
| Obligation | Who asks | Trigger | What you deliver | Legal force on the provider |
|---|---|---|---|---|
| SOC 2 examination (AICPA) | Enterprise buyers, mostly North American, and their third-party risk teams | Enterprise sales, security questionnaires | CPA firm report on controls relevant to security, availability, processing integrity, confidentiality or privacy | Contractual and commercial only |
| ISO/IEC 27001 certification | European and global enterprise buyers, public sector tenders | Tender requirements, supplier onboarding | Certificate from an accredited certification body, with a scope statement and Statement of Applicability | Contractual and commercial only |
| GDPR Article 28 processor terms | Any customer acting as controller of EU or UK personal data | Processing personal data on a customer's behalf | Data processing agreement with the Article 28(3) terms, sub-processor list, Article 32 security measures | Direct duties as processor plus contract |
| HIPAA business associate agreement | US covered entities (providers, health plans, clearinghouses) and other business associates | Creating, receiving, maintaining or transmitting PHI for them | Signed BAA, Security Rule safeguards for ePHI, breach and security incident reporting to the customer | Direct liability under the Security Rule plus contract |
| DORA Article 30 contract terms | EU banks, insurers, investment firms and other financial entities | Providing ICT services to a financial entity, with extra terms where the service supports a critical or important function | Contract schedule covering locations, data access and return, incident assistance, audit rights, TLPT participation, exit | Contractual, plus direct oversight if designated critical under Article 31 |
| NIS2 (Directive (EU) 2022/2555) | National competent authorities; also customers flowing down Article 21(2)(d) supply chain duties | Cloud computing service provider or managed service provider meeting size thresholds, as transposed nationally | Article 21 risk management measures, Article 23 incident reporting, registration | Direct, through national law |
| EU Cyber Resilience Act (Regulation (EU) 2024/2847) | Market surveillance authorities; customers that integrate your components | Placing a product with digital elements on the EU market (agents, SDKs, apps, devices) | Essential requirements, vulnerability handling, Article 14 reporting, conformity assessment, CE marking | Direct, on manufacturers |
| FedRAMP (20x and Rev5) | US federal agencies | Selling a cloud service for federal use | Certification package, continuous monitoring, listing on the FedRAMP Marketplace | Procurement condition for federal use |
| UK Cyber Security and Resilience Bill | UK regulators and the NCSC, once enacted | Medium and large managed service providers, data centres and digital service providers | Security duties, incident reporting to regulator and NCSC, notification of affected customers | Direct, if and when enacted |
For a side-by-side comparison of SOC 2, ISO/IEC 27001, CSA STAR and other attestations as a buyer sees them, see the Third-Party Attestation Comparison Map.
Market attestations: SOC 2 and ISO/IEC 27001
Neither is law, yet for most providers these are the first two items on the compliance roadmap because enterprise procurement will not move without one of them.
- SOC 2: the AICPA describes SOC as a suite of services CPAs provide on the system-level controls of a service organisation, giving users the information they need to assess the risks of outsourcing. A SOC 2 report covers controls relevant to security, availability, processing integrity, confidentiality or privacy; providers choose which categories beyond security to include. Buyers in North America generally expect a Type 2 report covering a period of operation. The AICPA has published proposed 2027 Trust Services Criteria as an exposure draft, so watch for changes to the criteria before your next period. See the SOC 2 Readiness Checklist.
- ISO/IEC 27001:2022: a certifiable management system standard. What buyers check is the certificate's scope statement (does it name the product they are buying), the certification body's accreditation and the Statement of Applicability. See the ISO 27001 Certification Guide.
- Which first: sell mainly into US mid-market and enterprise, start with SOC 2; sell into European enterprise or public tenders, start with ISO/IEC 27001; selling into both, run one control framework and plan for both within 12 to 18 months. The trade-offs are covered in SOC 2 vs ISO 27001 vs PCI DSS.
Customer-imposed legal terms: GDPR, HIPAA and DORA
These three arrive as contract paper. Each has a fixed list of clauses, so the efficient answer is a standard schedule you maintain, not a negotiation per deal.
| Term | GDPR Article 28 (processor) | HIPAA business associate agreement | DORA Article 30 (ICT third-party provider) |
|---|---|---|---|
| Security measures | Art. 28(3)(c): all measures required by Article 32 | Appropriate safeguards and Security Rule compliance (45 CFR Part 164 Subpart C) for ePHI | Art. 30(2)(c): availability, authenticity, integrity and confidentiality of data; 30(3)(c): tested business continuity plans and ICT security measures for critical or important functions |
| Subcontractors | Art. 28(2) and (4): prior written authorisation, same obligations flowed down, processor stays liable | Subcontractors handling PHI must agree to the same restrictions | Art. 30(2)(a): whether subcontracting of critical or important functions is permitted and on what conditions |
| Incidents | Art. 28(3)(f): assist the controller with Articles 32 to 36, including breach notification | Report unauthorised uses and disclosures, breaches of unsecured PHI (45 CFR 164.410) and security incidents to the covered entity | Art. 30(2)(f): assistance during ICT incidents at no extra cost or a cost agreed in advance |
| Audit and information | Art. 28(3)(h): information to demonstrate compliance, allow and contribute to audits | Books and records available to HHS | Art. 30(3)(e): unrestricted rights of access, inspection and audit for the financial entity and its competent authority |
| End of contract | Art. 28(3)(g): delete or return personal data | Return or destroy PHI if feasible, keep safeguarding what is retained | Art. 30(2)(d) data return; 30(3)(f) exit strategies with a mandatory transition period |
| Location | Transfers only on documented instructions, Art. 28(3)(a) | Not specified in the sample provisions | Art. 30(2)(b): locations of service and data, with advance notice of changes |
- DORA specifics: under Article 28(1) the financial entity stays fully responsible for compliance even when it outsources, which is why bank contracts are firm on audit rights and exit. Where your service supports a critical or important function, expect the Article 30(3) extras: quantitative service levels, notice of developments that affect delivery, participation in threat-led penetration testing and exit plans. See the DORA Article 30 Contract Provisions Guide.
- Critical provider designation: Article 31 lets the European Supervisory Authorities designate ICT third-party providers as critical, based on systemic impact, the importance of the financial entities relying on them, concentration on critical functions and substitutability. A designated provider gets a Lead Overseer, and a provider established outside the EU must set up an EU subsidiary within 12 months of designation. Few SaaS providers will be designated, but large horizontal platforms should track it. See the DORA Critical ICT Third-Party Provider Oversight Guide.
- HIPAA specifics: HHS's sample provisions make the business associate directly liable for failing to safeguard ePHI under the Security Rule, and the parties may agree a stricter reporting timeframe than the rule's outer limit. Agree in the BAA who notifies individuals, HHS OCR or the media. See the HIPAA Security Rule Guide.
Direct regulation: NIS2 and the UK Bill
NIS2 Annex I lists cloud computing service providers under digital infrastructure, and managed service providers and managed security service providers under ICT service management (business to business). Member States had to transpose the Directive by 17 October 2024 and apply it from 18 October 2024; national transposition is uneven, so check the law of your main establishment.
- Measures: Article 21(2) lists ten areas, from (a) risk analysis and information system security policies to (j) multi-factor or continuous authentication. For a SaaS provider the heaviest are (d) supply chain security, (e) security in acquisition, development and maintenance including vulnerability handling and disclosure, and (i) access control and asset management.
- Reporting: Article 23(4) sets an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours and a final report within one month of the notification.
- Penalties: Article 34 sets maximum fines of at least EUR 10 million or 2% of worldwide annual turnover for essential entities, and at least EUR 7 million or 1.4% for important entities, whichever is higher.
- Flow-down even if out of scope: Article 21(3) requires in-scope entities to consider each direct supplier's vulnerabilities, product quality and secure development practices, so customers that are NIS2 entities will ask you about them anyway. See the NIS2 Directive Guide.
- UK: the Cyber Security and Resilience Bill was introduced on 12 November 2025. As introduced, it would regulate medium and large managed service providers for the first time, bring data centres into scope, require reporting of significant incidents to the regulator and the NCSC within 24 hours with a full report within 72 hours, and require prompt notification of likely affected customers. Treat these as proposals until Royal Assent. See the UK Cyber Security and Resilience Bill Guide.
Product regulation: the Cyber Resilience Act
The CRA applies to manufacturers of products with digital elements placed on the EU market. A SaaS provider becomes a manufacturer the moment it ships software that runs on the customer's side: endpoint agents, on-premises connectors, mobile and desktop apps, SDKs, browser extensions or device firmware. Remote data processing that a product needs to perform its functions falls within the product's scope; the standalone hosted service generally sits under NIS2. The boundary is explained in NIS2 vs Cyber Resilience Act.
| CRA milestone (Article 71) | Date | What it means for a SaaS provider that ships software |
|---|---|---|
| Entry into force | 10 December 2024 | Start inventorying shipped components and their support periods |
| Chapter IV (notification of conformity assessment bodies) | 11 June 2026 | Notified bodies can be designated; relevant if any product is an important or critical product needing third-party assessment |
| Article 14 reporting | 11 September 2026 | Report actively exploited vulnerabilities and severe incidents affecting your products |
| General application | 11 December 2027 | Essential requirements, technical documentation, conformity assessment and CE marking for products placed on the market |
Article 64 penalties reach EUR 15 million or 2.5% of worldwide annual turnover for breaches of the essential requirements and Articles 13 and 14, and EUR 10 million or 2% for many other obligations. Microenterprises and small enterprises are exempt from fines for missing the Article 14 early warning deadlines. See the EU Cyber Resilience Act Guide.
US federal market: FedRAMP 20x and Rev5
FedRAMP is the route to having a cloud service used by US federal agencies. As of 14 November 2026 the programme runs two paths.
- FedRAMP 20x: FedRAMP states that the pilots are over and that Classes A, B and C are available now, with Class C aimed at enterprise services used across an agency. Class D (High) is planned for a later phase. FedRAMP granted its first full 20x Class C certification on 2 November 2026. See FedRAMP 20x.
- Rev5: FedRAMP will stop accepting new Rev5 certifications on 11 June 2027 and plans to publish a transition path for existing Rev5 offerings. A provider starting today should plan for 20x unless it needs a High baseline before Class D exists.
- Ongoing duties: both paths involve continuous monitoring after certification, and FedRAMP notices (for example NTC-0017 on vulnerability detection and response migration, published 10 November 2026) change operational reporting. Assign someone to read every notice. See the FedRAMP Guide.
Where one control serves many requests
The same few capabilities answer most of the obligations above. Build them once, document them once and map them.
| Capability | Answers | Design note |
|---|---|---|
| Incident response with customer notification | NIS2 Art. 23, CRA Art. 14, DORA Art. 30(2)(f), GDPR Art. 28(3)(f), HIPAA BAA reporting, UK Bill proposals | Design for the shortest clock you face (24 hours early warning) and keep a register of each customer's contractual notice period. See the SaaS Provider Incident Notification Guide. |
| Sub-processor and supplier management | GDPR Art. 28(2) and (4), DORA Art. 30(2)(a), NIS2 Art. 21(2)(d), HIPAA subcontractor terms, SOC 2 vendor management | One public sub-processor list with change notice; one supplier risk process with evidence |
| Vulnerability handling and disclosure | CRA essential requirements and Art. 14, NIS2 Art. 21(2)(e), FedRAMP continuous monitoring | Published disclosure policy, SBOMs for shipped components, defined remediation timelines |
| Data location, return and deletion | DORA Art. 30(2)(b) and (d), GDPR Art. 28(3)(a) and (g), HIPAA return or destroy | Documented regions, export format and deletion evidence per tenant |
| Audit and evidence access | DORA Art. 30(3)(e), GDPR Art. 28(3)(h), SOC 2, ISO/IEC 27001 | Trust centre with current reports, plus a defined process for regulator and customer audits |
| Access control and MFA | NIS2 Art. 21(2)(i) and (j), HIPAA Security Rule, SOC 2, FedRAMP baselines | Phishing-resistant MFA for staff, controlled support access to customer tenants |
What it means for non-human identities and AI agents
- Integration tokens are customer data access: OAuth grants and API keys that customers issue to your platform are in scope of their Article 28 and DORA due diligence. Expect questions on storage, scoping, rotation and revocation. See the SaaS API Token Security Guide.
- Support and automation accounts: service accounts and staff tooling with cross-tenant reach are where buyers probe isolation. Inventory them, scope them per tenant and log their use in a form you can share with customers.
- AI features: agents and model providers that touch customer data are sub-processors or suppliers; list them, and treat their credentials like any other privileged non-human identity.
Compliance steps
- Map your customer base: list which customers are EU financial entities, NIS2 entities, US covered entities, US federal agencies or controllers of EU personal data. That list decides your obligations more than your own sector does.
- Decide your own status: confirm with counsel whether you are a NIS2 cloud computing or managed service provider in your main establishment, and whether anything you ship makes you a CRA manufacturer.
- Stand up one control framework: an ISMS aligned to ISO/IEC 27001 with mappings to SOC 2 criteria, NIS2 Article 21 and FedRAMP if relevant.
- Write standard contract schedules: a DPA, a BAA if you serve US healthcare, and a DORA Article 30 schedule, each pre-approved so sales does not negotiate clause by clause.
- Build the incident clock: one process that can produce a 24 hour early warning, a 72 hour notification and customer notices, tested in an exercise.
- Prepare for CRA reporting: if you ship software, set up the Article 14 workflow now, since it already applies.
- Publish evidence: a trust centre with current reports, certificates, sub-processor list and disclosure policy, refreshed on a calendar.
- Review twice a year: transposition, FedRAMP notices, AICPA criteria changes and the UK Bill all move; assign an owner to each.
Practitioner checklist
- Keep a register of every customer-imposed security obligation, its source contract and its notice period.
- Confirm that SOC 2 and ISO/IEC 27001 scopes name the products customers buy.
- List every shipped component that could be a CRA product with digital elements and its support period.
- Test the incident process against the 24 hour, 72 hour and one month NIS2 clocks and the CRA Article 14 clock.
- Track FedRAMP notices and the June 2027 Rev5 cut-off if you sell or plan to sell to US agencies.
- Inventory integration tokens, support accounts and AI sub-processors, and include them in customer evidence.
Standards and references
- EUR-Lex: Regulation (EU) 2022/2554 (DORA)
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- FedRAMP: FedRAMP 20x
- AICPA: System and Organization Controls (SOC) suite of services
- GDPR: Article 28 Processor
- HHS: Business Associate Contracts, Sample Provisions
- GOV.UK: Cyber Security and Resilience Bill introduced
Related NHI Mgmt Group resources: Cybersecurity for SaaS Companies Guide · SOC 2 Readiness Checklist · Security Questionnaires Guide · DORA Article 30 Contract Provisions Guide. This guide summarises customer-driven and regulatory security obligations for SaaS providers as of 14 November 2026 and is not legal advice.