Compliance architecture for Azure: SOC 2, HIPAA, ISO 27001

We take the third path: the requirement is designed into the architecture, and the evidence is a by-product of the way you already deploy.

What “designed in” means concretely

Region restriction is a policy, not a preference. If personal information must stay in Canada, that is enforced at the management group level. Every future subscription inherits it. Nobody has to remember, and nobody can override it in a hurry on a Friday afternoon.

Access is granted by role and reviewed on a schedule. Entra ID with Privileged Identity Management, so standing administrative access does not exist. It is requested, time-bound, justified and logged. That single change answers a disproportionate share of any audit.

Change is controlled by the pipeline. Infrastructure changes arrive as pull requests, with an author, a reviewer, a test result and a timestamp. Change management stops being a form someone fills in afterwards and becomes a record that already exists.

Data is classified before it is protected. Microsoft Purview for cataloguing, sensitivity labels and DLP. You cannot protect what nobody has located, and “we think it is only in the main database” is the sentence that precedes a breach notification.

Evidence is exported, not assembled. Defender for Cloud regulatory compliance dashboards, Azure Policy compliance state, Log Analytics queries and pipeline history, mapped to the controls your auditor asks about, exportable per control.

Frameworks we design against

SOC 2 Type II. The trust criteria that consume the most effort are change management, logical access and monitoring. All three are architecture problems. We map policy assignments and pipeline gates to the control set, so the observation window records a system behaving correctly rather than a team behaving diligently.

HIPAA. PHI segmented into its own subscription boundary, encryption in transit and at rest, private endpoints on data services, audit logging retained for the required period, and a BAA-compatible service selection. We also document the data flow (where PHI enters, where it rests, where it leaves) because that diagram is what a security review actually wants.

ISO 27001. Annex A controls mapped onto Azure configuration, aligned to your existing ISMS rather than replacing it. Useful when a European or enterprise customer makes it a condition.

Quebec Law 25. Data residency enforced by policy, records of processing, privacy impact assessment support for any transfer outside Quebec, retention and deletion designed rather than improvised, and incident detection with the reporting path defined in advance.

GDPR and HDS. European residency, transfer boundaries documented, and health data hosting requirements where French healthcare data is involved.

How we work

Weeks 1-2: gap assessment. Current estate against the target control set. Output is a prioritized list with an honest cost against each item, and a clear statement of what is genuinely risky versus what is merely untidy. Those are different, and conflating them wastes budget.

Weeks 3-6: remediation as code. Policy set, identity model, network segmentation, logging and retention, deployed through pipelines. Every change reviewable and reversible.

Weeks 7-8: evidence layer. Control-to-artefact mapping, export queries and dashboards, and a runbook for whoever answers the auditor’s questions.

Ongoing: drift. Compliance decays. Policy compliance state and Secure Score are monitored, and drift raises an alert instead of surfacing at the next audit.

What you keep

A control matrix mapping each requirement to the Azure configuration that satisfies it.
The policy set as code, in your repository.
Export queries and dashboards producing evidence on demand.
A data flow diagram for regulated data, kept current by the same pipeline.
A written record of accepted risks: what you chose not to remediate, and why.

Who this is for

Organizations facing an audit for the first time, digital health and fintech companies blocked by an enterprise customer’s security questionnaire, and any Quebec organization that has read Law 25 carefully and realised it describes their architecture rather than their privacy policy.

Who this is not for

If you need a SOC 2 report by next quarter and have no architecture in place, we cannot help in that timeframe and will say so on the first call. Firms that promise it are selling you a document, and the gap between the document and the system is where incidents live.

Azure landing zone: where the policy set is enforced.
Cybersecurity, Entra ID and zero trust: the identity half.
Healthcare: the sector where this work has the sharpest edge.
Loi 25 and data residency: the Quebec-specific detail.

Questions we get

Can you get us SOC 2 certified?

No. Only a licensed CPA firm can issue a SOC 2 report, and we would not want to be both the builder and the auditor. What we do is make the audit uneventful: the controls are enforced by Azure Policy and by the deployment pipeline, and the evidence is exported rather than reconstructed. Clients typically arrive at the audit with the artefacts already in hand.

How long before we are audit-ready?

For an organization already on Azure with a reasonably clean estate, six to twelve weeks of architecture work before the observation window opens. If identity is unmanaged or change control is informal, longer. Those two are almost always the real gap, not encryption or firewalls.

Is Azure HIPAA compliant out of the box?

No platform is compliant on its own. Microsoft will sign a BAA covering in-scope services, which is necessary but not sufficient. Compliance depends on how you segment PHI, which services you use, how access is granted and reviewed, and what you log. That configuration is the work.

What does Loi 25 actually require of our architecture?

In architectural terms: know where personal information lives, be able to justify any transfer outside Quebec with a privacy impact assessment, be able to produce and delete an individual's data on request, and be able to detect and report a confidentiality incident. Each maps to something concrete: data inventory, region policy, retention design, logging and alerting.

We already passed an audit. Why would we need this?

Passing once with manual evidence usually means someone spent six weeks assembling screenshots. The question is whether year two costs the same. If evidence is produced by the pipeline, the recurring cost approaches zero and the controls stop drifting between audits.

Do you work with our existing auditor or GRC tool?

Yes. We build to the control set you are being measured against, and export in the format your auditor or platform expects. We have no preferred audit firm and take no referral fee from one, which is deliberate.

Have a question about this work?

Three fields. An architect reads it and answers within one business day.