Compliance Perimeter

Every system that touches regulated data inherits the regime's obligations: audit, retention, access control, change control, monitoring and periodic assessment.

The perimeter's size is therefore the dominant cost of a compliance programme — far more than the assessment itself — and it is set by where the data goes rather than by any compliance activity.

Why it matters

A small, deliberate perimeter means the obligations apply to a handful of systems designed for them. A sprawling one means an estate that acquired the obligations accidentally, and every future change to any of those systems carries the regime's cost.

The difference compounds: an expanding perimeter makes each subsequent assessment larger, each change slower, and each new system a scoping question.

Implementation patterns

• Never receive the data if possible. A hosted field or an SDK sending sensitive values directly to a compliant provider means they never enter your systems. The largest possible reduction, and a product decision made at design time.
• Tokenise at the earliest possible point, so everything downstream holds a token.
• Segment demonstrably. A segment is out of scope only if the restriction is enforced and can be evidenced — a diagram is not a control.
• Remove the data from where it accumulates: logs, error reports, support tooling, analytics, backups, non-production datasets. These are where the perimeter creeps invisibly, because nobody designed them to hold it and they do.
• Automated detection of regulated data outside the perimeter, with an alert and an owner. Scope creeps continuously, and only detection stops it — a policy prohibiting it is not a control, and the failure is silent.

Industry example

Payment platforms such as Razorpay and PhonePe live or die on this: the difference between a perimeter of five systems and one of fifty is the difference between a compliance function that supports the business and one that constrains it.

The same reasoning governs health data, personal data under privacy regimes, and anything with a sectoral regime attached — the regime differs and the perimeter logic does not.

Failure scenarios

• Encrypting and keeping the data, which does not remove it from scope.
• Segmentation asserted rather than enforced, discovered during assessment.
• Regulated data in logs, extending the perimeter to the log platform and everyone who can read it.
• Non-production environments with real data, a recurring breach source and a scope expansion at once.
• No detection, so the perimeter grows silently between assessments.

Trade-offs

Aggressive scope reduction constrains the product: not receiving the data means not being able to do things with it, and tokenisation means an extra hop and a vault that is now a hard dependency of anything needing the real value.

The vault also concentrates risk — one system holding everything — which is usually judged acceptable because protecting one system well is more achievable than protecting the data scattered across fifty.

Interview question

"List every system in your compliance scope, and for each one tell me why it is there. Then tell me which three you could remove and what it would take."