Chapter 28 — Privacy Platforms and Cloud-Native Tools

1. A module is not an obligation

Buying a privacy platform buys configurable software and contracted support. It does not supply the enterprise’s actual purpose decisions, accurate system inventory or operational ownership. A feature becomes part of a control only when its configuration, dependencies, failure behavior and evidence are understood. Even a successful test establishes only the behavior of the tested configuration and scope, not that an entire statutory obligation is permanently discharged.

The practical choice is rarely “suite or cloud.” A suite can provide case orchestration while discovery runs near separate data stores. A cloud service can identify data while an existing internal service handles requests and exceptions. Either architecture can fail at the seams. The decision therefore starts with the missing capability, the data movement it introduces and the team that must operate the resulting boundary.

This chapter preserves the capability-to-obligation method but removes a misleading shortcut: neither product breadth nor a familiar brand establishes end-to-end coverage. A documented module should earn a test request, not a green compliance cell. A component outside its documented scope should not be rejected for failing to be a whole platform.

2. A named, module-level shortlist

These entries are evidence-backed candidates, not rankings. “Unknown” means not established by the retained capture. Public pages can describe a broader commercial portfolio than the edition a bidder quotes; resolve that gap explicitly.

Product or service	What the retained source actually claims	What to test / selection implication (author recommendation)
OneTrust India DPDPA Compliance	Built-in DPDPA control frameworks, consent and rights automation, discovery/mapping, third-party governance and breach-response support.[12] Lines 33–71. This is solution marketing, not a retained API specification.	Ask for the quoted modules, versioned DPDP mapping, receipt export, target-system execution and excluded integrations. A suitable candidate for investigating horizontal workflows, not proven complete coverage.
Securiti PrivacyOps Platform	Explicit DPDP positioning and privacy-operations capability claims.[14] Lines 11–17. The retained navigation also names discovery/classification and breach-impact analysis.[14] Lines 164–204.	Request the architecture and actual consent/rights APIs; distinguish purchased privacy modules from adjacent security products. Test whether a case reaches the buyer’s processors rather than stopping at a workflow task.
BigID Privacy Suite	Discovery-linked privacy workflow claims: identity, consent, purposes, assessments, retention, minimization, enforcement and evidence.[16] Lines 32–121. Its separate India page still uses PDPB and sensitive/critical categories.[15] Lines 11–35.	Investigate data-to-workflow fit, but demand a current Act/final-Rules mapping. The stale legal page is not proof that the current product lacks useful features; it is not valid DPDP legal authority either.
Seqrite Data Privacy	Consent/preferences, rights cases, assessments, breach templates and integrations; modular licensing plus cloud, on-premise and hybrid options.[23] Lines 73–109, 189–219.	Include it in the privacy-platform comparison rather than a security-only bucket. Verify the exact entitlement, connector privileges, deployment and support boundaries.
Privado repository scanner	Repository scan, local JSON result and optional dashboard sync with a stated no-code-upload condition.[18] Lines 25–41.	Use as a code-flow discovery candidate. The retained quick start does not establish runtime rights/consent operations or a full-suite privacy manager. Request scan and synchronization behavior, not an unrelated DSAR feature score.
Microsoft Purview	The retained document describes data-security/compliance protections for generative-AI applications and distinguishes supported app categories.[29] Lines 29–63.	Evaluate the relevant app/module coverage and licensing. Do not turn an AI-protection document into evidence of a complete DPDP consent/rights implementation across the estate.
Google Sensitive Data Protection	Managed inspection/transformation, discovery and risk-analysis pricing; location documentation provides supported processing regions/endpoints.[34] Lines 21–35.[32] Lines 83–104.	Candidate managed discovery/de-identification primitives. Test the actual content method, location and unsupported-format path; a service name is not an estate-wide residency guarantee.
Google Assured Workloads India Data Boundary	A scoped control package for supported services/endpoints; global support personnel and restrictions are expressly noted.[33] Lines 79–114.	Separate hosting/control-package verification from DPDP transfer analysis. Inspect supported products, metadata, support access and fallback paths.
Amazon Macie	S3 general-purpose-bucket security posture and sensitive-data discovery; findings through console/API and EventBridge/Security Hub integration.[35] Lines 89–111.	Candidate S3 discovery component. Test formats, sampling, permissions and downstream findings integration; consent/rights operations outside that slice require other components.

Presidio belongs in the next chapter’s open-source detection discussion, not a managed cloud-service shortlist merely because Microsoft originated it. Product boundaries matter more than corporate family trees. Nor does the availability of detailed technical documentation constitute a measured quality advantage over a less documented suite; it reduces some research unknowns while leaving runtime fit untested.

3. Map capabilities without inventing statutory feature requirements

The table below is the author’s control design. The Act does not prescribe this exact inventory schema, event bus or evidence-store implementation. Apply the legal provision first, then choose a mechanism that can support it.

Capability	Legal purpose it may support	Client decision that the product does not make
Notice and consent records	Sections 5–6: notice, consent quality, withdrawal and proof when required.[1] Lines 167–268.	Necessary data, specified purposes, lawful request wording, applicable language options and separate grounds.
Rights case handling	Sections 11–14 and Rule 14: scoped access/correction/erasure, grievances and nomination.[1] Lines 441–495.[40] Lines 1294–1318.	Request scope, actor authority, sharing exceptions, retained-data decisions and truthful partial responses.
Discovery and classification	Supports scope analysis and control operation; Section 8(3) has a particular accuracy trigger, not a general “scanner required” mandate.[1] Lines 338–344.	Coverage denominator, accuracy implications for decisions/disclosure, unknown stores and validation method.
Retention and erasure	Sections 8(7), 12(3), and Rule 8(3), alongside other applicable law.[1] Lines 351–359, 473–476.[40] Lines 1153–1166.	Eligibility, purpose-specific restrictions, legal holds, disposal review and reconciliation after restore.
Incident workflow	Section 8(6) and Rule 7.[1] Lines 348–350.[40] Lines 1112–1139.	Whether a personal-data breach occurred, awareness time, affected people, notification content and delivery uncertainty.
Assessment and audit support	Conditional SDF requirements under Section 10 and Rule 13.[1] Lines 404–438.[40] Lines 1276–1293.	Designation, assessment judgments, independence and government-specified data scope. Templates do not appoint an auditor.
Location controls	Section 16 and Rule 15, plus applicable sector restrictions.[1] Lines 515–522.[40] Lines 1319–1323.	The transfer position for the actual activity, recipient and data; a regional endpoint is only one technical fact.

These core legal/control examples assume the retained scheduled commencement remains unchanged. The Act notification and Rules have distinct tranches; the corrigendum must be read with Rule 1.[39] Lines 49–59.[40] Lines 1005–1010.[41] Lines 25–38. Procurement can prepare capability before commencement, but a future readiness requirement must not be described as a currently triggered duty simply to strengthen a sales case.

4. The four integration seams, priced once

A suite can make central workflow visible while leaving actual enforcement distributed. The following cost drivers are author-designed procurement questions, not measured market prices.

Seam	Contracted boundary	Cost drivers to request	Negative acceptance scenario
Identity and representation	Map verified actor, subject and authority to the case system.	IdP integration, account resolution, delegated authority, role administration and recovery support.	A nominee request must not overwrite the subject identifier; an unauthorised actor receives no case content.
Consent/authority events	Carry trusted purpose/sequence and withdrawal state to enforcement points.	API/event limits, replay storage, adapter development, deduplication, monitoring and outage support.	A late old grant cannot revive withdrawn marketing; an unavailable acknowledgement remains unresolved.
Deletion/restriction execution	Convert a reviewed retention decision into scoped actions and processor tasks.	Write-capable connectors, retries, exception handling, restricted archives and restore testing.	Active use remains denied while lawfully retained data is restricted; an orphan eligible copy is not called erased.
Evidence and exit	Export configuration, decisions, tests and results with their relationships.	Storage volume, retention, access controls, format conversion, support and migration assistance.	The buyer must reconstruct a failed case after removing vendor administrative access.

The seam can be owned by the suite vendor, an integrator or the client, but someone must accept it. “We integrate with CRM” is insufficient if the connector only reads contacts and cannot reconcile correction or suppression state. The RFP should state required actions per system and the consequences of partial success. Assign cost and evidence ownership to the interface, not only to the endpoint products.

Price native meters rather than forcing unlike services into a cost-per-person ranking. Google lists inspection/transformation, discovery and risk analysis as separate components and warns that cancelled work can still incur charges.[34] Lines 11–35. Macie lists buckets, monitored objects and inspected data; targeted discovery also incurs S3 request charges.[36] Lines 85–99. A suite quote may instead depend on modules, seats, connectors or service hours. Compare complete scenario costs only after specifying each meter and any client work left outside the quote.

5. Location is a behavior of the whole path

Google’s retained location table lists Mumbai, Delhi and an India multi-region.[32] Lines 149–150, 195. That fact does not settle every operation. The same document’s image-scanning list does not include those India entries, and describes binary scanning or a fallback location for unsupported image-processing locations.[32] Lines 201–224. This is a material distinction for a buyer whose documents contain scanned identity information. A proposal cannot quietly switch to a non-India fallback just to improve recognition while claiming the original boundary remains intact.

The author’s recommended PoV records input location, chosen method, endpoint, actual processing path, results location, telemetry and support paths. An unsupported format must be an explicit unknown or separately approved route. “No findings” after binary scanning is not proof that an image contains no personal data. The decision can be to use a different local image-processing component, narrow the scope or stop that flow until its location/quality conflict is resolved.

The India Data Boundary source also states that support cases route to global support personnel and that unlisted products are unsupported by the package.[33] Lines 93–114. This is not proof that every support interaction transfers customer content abroad, but it defeats an unqualified inference that every operational path is India-only. Require a data-flow and access assessment for the actual configuration. The legal transfer determination remains distinct, including sector rules and any applicable notification or order, rather than a checkbox inherited from a region name.

6. Two architectures with different decisions

In hypothetical Architecture A, the Company already has case service SYS-011 and authority ledger SYS-010, but discovery across object stores is weak. A managed component near each store may be the narrow purchase. Macie’s documented S3 behavior makes it a candidate for an S3 slice, not for SQL, CRM or processor-copy erasure.[35] Lines 93–111. The client should preserve its existing workflow and fund an adapter that links findings to inventory owners. The decision does not depend on calling suites expensive or primitives superior; those claims have not been measured.

In hypothetical Architecture B, a retailer has basic discovery but no consistent case lifecycle. The suite candidates in the table become more relevant. A buyer-controlled scenario combines a verified access request, consent withdrawal, a lawful-retention exception and a missing processor acknowledgement. The desired outcome is not a universal success banner. It is a correctly split case: completed scoped actions, restricted retained data and an unresolved task that prevents false completion. An operator must be able to explain and export each branch.

Suppose a fictional suite proposal covers consent and case orchestration but excludes the legacy connector. This is not evidence that any named supplier failed. It is a decision exercise: the buyer can accept the narrower scope only after assigning and testing the missing interface, or exclude the affected workflow from launch. Paying for a whole-suite licence does not make an omitted connector disappear. Conversely, poor measured quality in one future discovery test need not force replacement of an otherwise acceptable case module; re-scope by capability if the remaining architecture can still meet its applicable requirements.

7. Keep the privacy tool inside the privacy design

A central privacy platform may store identity links, requests, contact details, consent history and evidence about exceptions. Those records need purpose, access and retention decisions too. Minimise payloads where references or restricted extracts suffice; separate operational case data from evidence needed for a particular purpose. Do not copy the full customer record into every audit packet because an export button exists.

A useful evidence package contains product/edition and configuration identities, source mapping, the target-system denominator, synthetic inputs, expected behavior, actual observations, defects, decisions and retest history. Retain “not run” and “unsupported” as first-class states. Neither screenshots nor checksums prove the underlying action happened; a checksum proves identity of the captured bytes. Subsequent releases, connector changes and newly discovered stores can invalidate a prior conclusion and trigger bounded retesting.

At exit, export policies, notices, consent/authority history, case relationships and unresolved work as well as completed records. Test import into a neutral replacement representation and reconcile counts and meaning before deleting anything. Continued lawful retention and restricted evidence can survive a platform migration; their existence must not be misrepresented as vendor failure or permission for commercial reuse.

Chapter 29 asks when the client should own more of this implementation itself. The decision is not between proof and no proof. It is between different allocations of engineering, operational and evidence responsibilities.

Source notes

The generated sources identify the exact retained pages. out/remediation/q08/source-manifest.json preserves URL, retrieval metadata, newline-counted source identity and SHA-256. All selection and architecture implications are author analysis, not vendor demonstrations.

Retained file map

The line ranges cited above refer to these exact local captures:

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf [12] https://www.onetrust.com/solutions/india-dpdpa-compliance [14] https://securiti.ai/solutions/india-digital-personal-data-protection-act [15] https://bigid.com/compliance/pdpb-compliance [16] https://bigid.com/privacy-suite [18] https://docs.privado.ai/getting-started-with-privado/getting-started-with-privado [23] https://www.seqrite.com/data-privacy [29] https://learn.microsoft.com/en-us/purview/ai-microsoft-purview [32] https://docs.cloud.google.com/sensitive-data-protection/docs/locations [33] https://docs.cloud.google.com/assured-workloads/docs/control-packages/india-data-boundary [34] https://cloud.google.com/sensitive-data-protection/pricing [35] https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html [36] https://aws.amazon.com/macie/pricing [39] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [40] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [41] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E)

Contents · Reader guide and citation conventions · Artifact index