A practical, evidence-based compliance checklist covering AI governance, privacy, consent, accessibility, and security — the five areas that stall enterprise deals and trigger regulator questions.
Compliance requirements for SaaS and AI companies no longer live in a single framework. A modern B2B product is judged simultaneously by privacy regulators, accessibility law, marketing-consent statutes, emerging AI rules, and — most often in practice — an enterprise buyer's security questionnaire. This checklist covers what each of those readers actually looks for, and what evidence satisfies them.
Who this checklist is for
This is written for AI and SaaS companies between first enterprise deal and Series B — the stage where a security questionnaire, a procurement review, or a data protection addendum becomes the thing standing between you and revenue. If you are shipping a product that processes customer data, uses a model to influence a decision, runs marketing automation, or has a public marketing site, every section below applies to you.
ComplyMynt is not a law firm and this article is not legal advice. It is an engineering-oriented view of what regulators, auditors, and enterprise procurement teams request, and what artifacts hold up when they do.
1. AI governance and transparency
AI-specific obligations are the newest and least standardized part of the checklist, which is why they generate the most questionnaire friction. The consistent theme across the EU AI Act, state-level automated-decision rules, and enterprise AI addenda is the same: disclose what the system decides, what it uses, and how a human can intervene.
- Maintain an inventory of every model and AI feature in the product, including third-party APIs, with the decision each one influences.
- Publish a disclosure at the point of the decision — not only in a policy page — naming the decision, the data categories used, and the human review path.
- Confirm in writing that model vendors do not train on your customers' data, and list them as subprocessors if they receive personal data.
- Document human oversight for any decision with legal or material effect, including who reviews, on what signal, and within what timeframe.
- Record training-data provenance and any licensing constraints on datasets used to fine-tune models.
- Keep evaluation and red-team notes for accuracy, bias, and harmful-output testing — buyers increasingly ask for the artifact, not the assurance.
2. Privacy: notices, data flows, and rights
Privacy is the most mature area on this list, so the bar is correspondingly higher. The common failure is not a missing policy but a policy that no longer matches the product: a privacy notice describing three subprocessors while the codebase calls nine.
- Produce a data flow map covering collection points, storage locations, retention windows, and every onward transfer.
- Keep a subprocessor list that matches reality, with executed data processing agreements and a change-notification commitment.
- Make GDPR/CCPA rights operable end to end: access, deletion, correction, portability, and opt-out of sale or sharing, each with an owner and an SLA.
- Implement Global Privacy Control handling if you serve California residents.
- Set and enforce retention limits in the database, not only in the policy text.
- Confirm a lawful transfer mechanism for any cross-border flow, including standard contractual clauses where applicable.
3. Consent: cookies, trackers, and marketing
Consent splits into two distinct problems that teams usually conflate. Web consent governs what loads in the browser. Marketing consent governs whether you may call, text, or email a person. Both are enforced against evidence, and both fail quietly.
On the web side, the most common finding we raise is that a consent platform is configured correctly while something upstream of it is not: a hardcoded pixel in the page template, a tag manager that initializes before the consent state resolves, or a server-side container forwarding events that never touched the browser.
- Load no non-essential cookie, pixel, or local-storage identifier before an affirmative opt-in in consent-required regions.
- Set a denied default consent state before the tag manager script, and verify with a clean-profile network trace rather than a dashboard screenshot.
- Audit server-side tagging and CDN edge workers — client-side scanners cannot see them.
- Store marketing consent records with four elements: verbatim disclosure text, timestamp, capture source, and a version identifier for the language.
- Record revocation with the same fidelity as the original consent, and retain both for the full limitations period.
- Test producibility: pick one record at random and try to assemble the full packet in under an hour.
4. Accessibility (WCAG 2.2 AA)
Accessibility appears in enterprise procurement as a VPAT or ACR request and in law through the ADA, Section 508, and the European Accessibility Act. Automated tooling reliably finds roughly a third of issues; the rest live in focus order, custom widgets, and error messaging.
- Run automated checks in CI to catch contrast, alt text, and unlabeled inputs on every build.
- Add one manual keyboard pass and one screen-reader pass per critical journey — signup, checkout, and core product flow — each release.
- Fix focus management first: modal focus traps, drawer focus return, and visible focus indicators.
- Give custom widgets real semantics: role, state announcement, and keyboard activation.
- Announce validation errors programmatically, not only visually.
- Publish a conformance statement and an accessibility contact, and keep the known-issues list honest.
5. Security and public trust surface
Enterprise reviewers read your security page before your pricing page. Much of what they check is externally observable, which means gaps are found without your involvement.
- Publish a responsible disclosure policy with scope, safe harbor, a reachable contact, and a response-time expectation you can meet.
- Serve a security.txt file at the well-known path.
- Enforce transport security headers: HSTS, a real content security policy, and correct cookie flags.
- Enforce SSO, MFA, and least-privilege access internally, and review access on a schedule.
- Maintain an incident response plan with defined notification timelines, and rehearse it.
- Track dependency and infrastructure vulnerabilities with an owner and a remediation clock.
6. Legal and policy pages
- Terms of service, privacy policy, cookie policy, acceptable use, and an AI disclaimer that matches how the product actually behaves.
- Billing, refund, and cancellation terms that reflect what the billing system enforces.
- Accurate marketing claims: no unverifiable statistics, implied certifications, or fabricated customer outcomes.
- A DMCA or copyright process if users can upload content.
- Version history for each policy, so you can show what a specific user agreed to on a specific date.
How to run the checklist: Scan, Assess, Fix, Verify, Monitor
A checklist reviewed annually as a document produces policies. A checklist run as a loop produces evidence. The sequence that works is simple.
Scan the live product and marketing surface for observable behavior — requests, headers, tags, storage, semantics. Assess each finding by severity and by who would raise it: regulator, buyer, or user. Fix in priority order, in code, with the change tracked. Verify with a re-scan that produces an artifact showing the behavior changed. Then monitor continuously, because every deploy, new pixel, and new vendor can reopen a closed finding.
The output you want at the end is not a passing grade. It is a findings register with owners, dates, and evidence — the same document the other side's counsel would otherwise write about you.
The five failures we see most
- Analytics and ad tags firing before consent in EU traffic, usually from a hardcoded script tag.
- A subprocessor list that is out of date by two or more vendors, discovered during diligence.
- AI disclosure that names the technology but not the decision, the data, or the human review path.
- Keyboard traps in modals and custom dropdowns that pass every automated scan.
- Marketing consent stored as a boolean, with no record of the language the person actually saw.
Frequently asked questions
- What compliance is required for a SaaS company?
- There is no single SaaS compliance standard. Most B2B SaaS companies must address privacy law (GDPR, CCPA and similar state laws), cookie and tracker consent, marketing consent rules such as TCPA and CAN-SPAM, accessibility under the ADA and WCAG 2.2 AA, and the security controls enterprise buyers require in questionnaires and contracts. Frameworks like SOC 2 and ISO 27001 are optional certifications, but procurement teams often treat them as expected.
- What compliance requirements apply specifically to AI companies?
- AI companies inherit every SaaS requirement and add AI-specific obligations: disclosing that an automated system influences a decision, documenting the data used, providing human oversight and a contestation path, confirming that model vendors do not train on customer data, and keeping records of training-data provenance and evaluation testing. The EU AI Act and state automated-decision rules are the main drivers, and enterprise AI addenda now ask the same questions contractually.
- Do early-stage startups need to be compliant before their first enterprise customer?
- Practically, yes. The first enterprise deal usually arrives with a security questionnaire, a data processing addendum, and sometimes an accessibility conformance request. Addressing the checklist before that point is far cheaper than renegotiating a stalled contract, and gaps discovered by a buyer's counsel get priced into the deal.
- Is SOC 2 enough to satisfy enterprise buyers?
- SOC 2 covers security and operational controls; it does not cover cookie consent, marketing consent records, accessibility conformance, or AI disclosure. Buyers increasingly ask about all of those separately, so SOC 2 is a strong component of the answer rather than the whole answer.
- How often should a SaaS compliance checklist be reviewed?
- Continuously for anything observable on the live site — tags, headers, cookies, accessibility regressions — because a single deploy can reopen a closed finding. Policy and documentation reviews work well quarterly, with a full assessment annually or whenever the product, data flows, or vendor set changes materially.
Want this checked on your product?
We run the same review across privacy, consent, accessibility, AI disclosure, and public security surfaces — and ship the remediation.
Request an audit
