Security Compliance

Core thing to get straight: compliance is a sales function, not a security function. Certifications don’t make you secure — they prove to a buyer’s procurement team that you have controls, documented, operating, and independently checked. The security work is worth doing regardless; the certificate is what unblocks the deal. Confusing the two is how companies spend $60k on SOC 2 and still ship a tenant-isolation bug.
Author

Benedict Thekkel

The certification landscape

Framework What it is When you need it
SOC 2 Type II AICPA attestation report on controls over an observation window. Not a certification — an auditor’s opinion. US buyers, mid-market and up. The default ask in North America.
ISO/IEC 27001:2022 Certifiable ISMS standard. Accredited body issues a 3-year certificate with annual surveillance. Australian, EU, and enterprise buyers. Better recognised outside the US.
ISO/IEC 27701 Privacy extension to 27001 — a PIMS. Signals privacy maturity; useful in health.
ISO/IEC 27017 / 27018 Cloud security / cloud PII controls. Cheap add-ons to a 27001 audit. Ticks boxes on questionnaires.
ISO/IEC 42001 AI management system. Relevant the moment you ship an ML-derived outcome prediction.
HIPAA US health data. Not a certification — you attest, and sign BAAs. Only if you have US covered-entity customers.
GDPR EU/UK. Also not certifiable. DPA + SCCs + Art. 30 records. EU customers or EU data subjects.
Essential Eight (ACSC) Maturity Levels 0–3 across eight mitigations. Australian government and enterprise questionnaires reference it constantly.
IRAP Australian government assessment against the ISM. Only for Commonwealth/state government hosting. Expensive.
HITRUST CSF Prescriptive, health-focused, certifiable. US hospital systems sometimes mandate it. Very costly.
PCI DSS Card data. Almost certainly avoidable — use Stripe and stay SAQ-A.

My recommendation for an Australian MedTech SaaS: ISO 27001 first, SOC 2 second, and only when a named deal requires it. ISO is better recognised by Australian health customers, produces a reusable management system rather than a point-in-time report, and the certificate is a one-page artifact you can hand over — SOC 2 reports are 60+ pages under NDA, which procurement teams find annoying. Do them together if you’re also selling into the US; the control overlap is roughly 80% and joint audits are commonly discounted.

SOC 2 mechanics

  • Trust Services Criteria: Security (mandatory, “Common Criteria”), Availability, Confidentiality, Processing Integrity, Privacy. Scope to Security + Availability + Confidentiality. Add Privacy only if a customer demands it — it roughly doubles the work and Australian law already covers you.
  • Type I = design of controls at a point in time. Type II = operating effectiveness over a window, typically 3 months (first report) then 12 months. Type I is a stepping stone with limited sales value; several buyers won’t accept it. Go Type II with a 3-month window if you’re time-pressured.
  • Timeline: 2–4 months of readiness/remediation, then the observation window, then 3–6 weeks of fieldwork and report writing. Realistically 6–9 months from cold start.
  • Cost: AU$15–35k for the audit itself at startup scale, plus AU$10–25k/yr for a compliance automation platform, plus a penetration test (AU$8–20k). Budget AU$40–70k for year one, roughly 60% of that recurring.
  • Exceptions in the report aren’t fatal — a report with two documented exceptions and management responses is normal. A report with a qualified opinion is a problem. Auditors vary wildly in rigour; a cheap auditor’s clean report gets discounted by sophisticated buyers who recognise the firm.

ISO 27001 mechanics

  • The ISMS is the deliverable, not the controls. Scope statement, risk assessment methodology, risk register, risk treatment plan, Statement of Applicability justifying each of the 93 Annex A controls as applicable or not, internal audit programme, and management review minutes. Auditors spend more time on those than on your infrastructure.
  • Annex A 2022 structure: 93 controls in four themes — Organisational (37), People (8), Physical (14), Technological (34). Eleven controls were new in the 2022 revision: threat intelligence, cloud services security, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, secure coding.
  • Audit cycle: Stage 1 (documentation review) → Stage 2 (full audit) → certificate → surveillance audits at 12 and 24 months → full recertification at 3 years.
  • Use a JAS-ANZ accredited certification body. Unaccredited certificates exist, are cheaper, and get rejected by careful buyers.
  • The 2022 transition deadline has passed — any certificate you obtain now is against the 2022 edition.

The controls that actually matter

Every framework converges on the same list. This is the engineering work:

Access - SSO + MFA everywhere, enforced, no exceptions for founders. - RBAC with documented least privilege; quarterly access reviews with evidence (a signed spreadsheet is genuinely acceptable). - Joiner/mover/leaver process with same-day deprovisioning. Auditors will pick a terminated employee and demand the timestamps. - No shared accounts. No long-lived cloud keys — OIDC federation for CI, IAM roles for compute.

Data - Encryption in transit (TLS 1.2+, HSTS) and at rest (KMS-managed, key rotation documented). - Documented data classification and retention schedule, with actual deletion jobs — not just a policy claiming deletion happens. - Backups encrypted, and restore tested with a dated record. Untested backups fail audits and disasters equally.

Change - Version control with mandatory peer review on protected branches. Branch protection is auditable evidence; a “we always review” claim is not. - CI/CD with automated tests, dependency and secret scanning, SAST. Deployment approval trail. - Separated environments; no production data in dev or staging, ever. For health data this is the one that ends companies. If you need realistic data, build a synthetic generator.

Monitoring - Centralised, tamper-resistant logging with defined retention (12 months is the common expectation). - Alerting with a documented on-call path and evidence of triage. - Vulnerability management with SLAs by severity (e.g. critical 7 days, high 30) and patch evidence.

Process - Incident response plan, tested annually via tabletop, with the NDB 30-day assessment clock built in. - BCP/DR with stated RTO/RPO and an annual test. - Vendor risk management: subprocessor register, their certifications on file, review cadence. - Security awareness training annually, background checks on hire, signed policy acknowledgements. - Annual penetration test by an external firm; remediation tracked to closure.

SaaS-specific: multi-tenancy

The architectural risk no framework asks about clearly, and the one that will actually hurt you:

  • Tenant isolation is your highest-severity bug class. Postgres Row-Level Security with a session-scoped tenant ID gives you defence at the database layer rather than relying on every Django queryset having a .filter(clinic=...). In Django, a middleware setting SET LOCAL app.tenant_id plus RLS policies means a forgotten filter leaks nothing. This is cheap insurance and I’d implement it before any certification work.
  • Write an automated isolation test suite — for every endpoint, tenant A’s token requesting tenant B’s object IDs must return 404, not 403 (403 confirms existence). Run it in CI. This is the single highest-value security test in a multi-tenant SaaS.
  • IDOR via sequential IDs — use UUIDs for anything externally referenced.
  • Background jobs and exports are the usual isolation blind spot: Celery tasks and CSV generators frequently bypass the request-scoped tenant context.
  • Per-tenant encryption keys get asked about by enterprise health buyers. Usually over-engineering at your stage; know the answer (“KMS-managed, per-region, with envelope encryption”) and move on.

The commercial artifacts

You’ll need these regardless of certification:

  • Security questionnaires — SIG Lite, CAIQ, or the customer’s bespoke 300-row spreadsheet. Maintain a canonical answer bank; this is the highest-ROI hour you’ll spend. A trust centre page (public policies, certs, subprocessor list, uptime) deflects a meaningful fraction of them.
  • Data Processing Agreement with subprocessor list and change-notification terms.
  • BAA if any US covered entity is involved.
  • Clear shared responsibility documentation — what you secure vs what the clinic secures. Clinics will ask who’s liable when their receptionist reuses a password.

Automation platforms

Vanta, Drata, Secureframe, Sprinto. Use one. They connect to AWS/GCP, your IdP, HR system and repos, continuously collect evidence, and map it to multiple frameworks at once. AU$10–25k/yr, and they save more engineering time than they cost.

Honest limits: they automate evidence collection, not control implementation. They produce a dashboard that says 94% compliant while your policies are unread boilerplate and nobody has ever run the incident tabletop. Auditors have learned to look past the dashboard. Treat the tool as a filing cabinet, not a compliance strategy.

Sequencing for where you likely are

  1. Now, regardless of customers: Australian region hosting, MFA + SSO, RLS tenant isolation, no prod data outside prod, encrypted tested backups, a written NDB response runbook, a real privacy policy and collection notice. All engineering-cheap, all legally required, none of it needs an auditor.
  2. When the first deal stalls on security: trust centre page, questionnaire answer bank, DPA template, subprocessor register. Weeks, not months.
  3. When a named deal requires a certificate, or you’re raising: pick ISO 27001, buy a platform, allow 6–9 months.
  4. Don’t start compliance work speculatively before a customer asks. It’s a six-figure distraction that produces nothing a pre-PMF company needs. The exception is the legal baseline in step 1 — that isn’t optional and isn’t compliance, it’s just the job.

Failure modes

  • Treating the certificate as the goal, then failing surveillance a year later because nobody ran access reviews.
  • Scoping SOC 2 to include Privacy TSC because it sounded thorough.
  • Production data in a staging database “just for debugging this one thing”.
  • No subprocessor register, then discovering an engineer wired in a US analytics SaaS that receives patient identifiers in URL paths.
  • Assuming the small business exemption applies. It doesn’t, for you.
  • Policies written by the platform’s template generator that describe a company you aren’t. Auditors interview staff; when your policy says quarterly access reviews and no one has done one, that’s an exception.
Back to top