What platforms built for SOC 2 miss about regional frameworks

Compliance automation as a category grew up around two buyers: North American software companies pursuing SOC 2, and international companies pursuing ISO 27001. The products are well designed for that. The design assumptions become visible the moment a regional framework enters, and they are specific enough to test for.

Gap 1 — Binary scoring

SOC 2 asks whether a control operated. ISO asks whether the system conforms. Both are effectively binary at the control level, so platforms model controls as satisfied or not.

SAMA CSF scores maturity on a six-level scale, and the difference between level 3 and level 4 is whether the control is measured and reported — not whether it works. A binary model cannot express that, so organisations end up tracking maturity in a spreadsheet alongside the platform, which defeats the purpose.

Gap 2 — Framework libraries

"Supports any framework" usually means you can import a control set and map to it yourself. That is materially different from a maintained library where the vendor tracks revisions when an authority updates the controls.

The test: ask to see the specific control set, at the version you will be assessed against, and ask what happens when the authority publishes a revision. Who updates it, and how quickly?

Gap 3 — Language

Arabic support is frequently an interface translation. What regional engagements require is Arabic output — policies, evidence descriptions, assessment reports — because that is what government entities and some regulators expect to receive.

This is not a cosmetic gap. Retrofitting translation across a policy set and an evidence base under tender pressure is slow, expensive, and reliably done badly.

Gap 4 — Applicability and residency

Two related blind spots:

• Applicability logic. Saudi derives scope from entity type and sector; Qatar from data classification; the UAE from sector and criticality with emirate-level requirements layered on. Platforms that assume one scope per organisation cannot represent a control that is in scope for one framework and out for another.
• Data residency as a control concept. Regionally, where data sits is a compliance requirement in its own right, extending to backups and support access. Most platforms model residency as a fact about their own hosting, not as something your control set must assert and evidence.

How to test for all four

1. Ask for the regional control set by name and version, and the revision process.
2. Ask it to score one control both ways — implemented for the ECC, maturity level for SAMA — from one evidence item.
3. Ask for a sample assessment report in Arabic.
4. Ask how a control in scope for one framework and out of scope for another is represented.
5. Ask where your evidence is stored, backed up, and accessible from.

These are answerable in a single call. A vendor that handles all five comfortably is built for your problem; one that deflects on three is built for someone else's, which does not make it a bad product.

The fair conclusion

None of this makes SOC 2-oriented platforms poor tools. If your obligations are SOC 2 and ISO 27001, they are likely the better choice — deeper integrations, larger ecosystems, more mature products. The mismatch is specific: it appears when a national framework, a maturity model, Arabic output or residency enters the requirement set. Match the tool to the obligations you actually have.

Key takeaways

• Binary control models cannot express maturity levels.
• "Any framework" often means you maintain the mapping forever.
• Arabic output, not interface translation, is what engagements require.
• Scope must vary per framework without duplicating the control.