Choosing Where to Begin

A company reading the Digital Personal Data Protection Act 2023 and the Rules made under it faces a long list of obligations arriving together. Notices, consent, rights, grievances, retention, erasure, security safeguards, breach reporting, processor contracts and record keeping.

Read as a single programme, that list produces a familiar reaction. The work seems large enough to need a proper plan, the proper plan needs a proper assessment, and the assessment needs somebody with time. Months pass and nothing operational has changed.

The other common reaction is to start with whatever is most visible, and that is usually the privacy notice. A new notice gets published, everybody feels progress has been made, and none of the underlying work has happened. The notice describes processing nobody has mapped and promises rights nobody can deliver.

Both reactions come from treating the Act as one thing. The Act sets out obligations touching different parts of a company, and they can be brought under control in an order.

Bringing everything into a platform at once means configuring the whole company before anything becomes usable. Configuration takes months at that scale, the people contributing lose interest, and the early records age while the later ones are still being gathered.

Bringing in one area means the platform is doing real work within weeks. The people who contributed see something running, which makes the next request for their time easier. And the configuration of the second area benefits from what the first one taught about how the company describes itself.

The order matters less than the fact of having one. A company working through areas in a defined sequence makes visible progress and can say where it has reached. A company working on everything simultaneously is busy without being able to state its position.

A scoped gap assessment is a short piece of work that produces the information needed to plan properly. It establishes five things.

Your current position, meaning what already exists. Many companies have more than they think, with a notice, some contracts and a partial system list, and knowing what is usable saves repeating it.

The responsible teams, meaning who would own each area if work started. That question frequently has no ready answer, and discovering the gaps in ownership is one of the more useful outputs.

The priority gaps, meaning where the distance between the obligations and the current position carries the most exposure. The technical dependencies, meaning which systems hold the data that the obligations reach and how difficult each will be to work with. And a practical implementation sequence built from all four.

None of that requires a lengthy engagement. What it requires is access to the people who know how the company works, and a willingness to record honestly what is missing.

An assessment that reports a company as broadly compliant with minor gaps has produced a comfortable document and no plan. The value lies in the specifics, including the uncomfortable ones.

Which systems hold personal data that nobody owns. Which processors have no adequate contract terms. Whether retention rules exist and whether anything enforces them. Whether a rights request could actually be answered completely today. Whether logs would support a breach investigation.

Answering those honestly produces a list somebody can work from. Answering them optimistically produces a plan built on a picture of the company that does not match the company, and the mismatch surfaces during the work.

The assessment is also the point at which a company learns how much it does not know about its own data. That figure determines the length of the first phase more than any other factor, and establishing it at the start beats discovering it in the middle.

Any of the operating areas can be brought into the platform first. Personal data mapping. Purposes and notices. Consent and withdrawal. Rights requests and grievances. Retention and erasure. Breach readiness. Processor oversight. Impact assessments. Evidence.

Each of those is a defensible starting point in the right circumstances, and the right one depends on the company and not on a general rule.

What settles it is usually a combination of where the exposure is greatest and where the company is already feeling difficulty. An area that is causing weekly difficulty gets attention and gets used. An area chosen because a framework recommends it competes with everything else for the same people time.

A company that cannot say where its personal data sits should start with the inventory, because every other area depends on it. Rights requests search it, retention applies to it, breach reports describe it, and notices describe what it contains.

A company already receiving rights requests and handling them by email should start there. The response periods are running, the work is visible, and intake is where most of the time is lost. Bringing requests into one place with dates, owners and a search that covers a known list of systems produces an immediate improvement.

A company with substantial vendor arrangements and thin contracts should start with processor oversight, because renegotiation depends on counterparties and takes calendar time nobody can compress.

A company holding sensitive categories at volume, or one that considers designation as a Significant Data Fiduciary plausible, should start with the inventory and move quickly to impact assessments and evidence, since those are the duties that arrive with the least warning.

The measure of a first phase is whether one area of the programme now operates properly. That means the records for it exist and have been confirmed by their owners, the obligations in it have become assigned work with dates, the exceptions are visible, and the evidence is accumulating as the work happens.

Companies that measure the first phase by how much of the company was mapped tend to be disappointed, because mapping a whole company takes longer than any first phase should. Companies that measure it by whether one area now runs get a truer picture and a platform doing real work while the rest is brought in.

The phase should also end with a clear view of what remains. Which areas are not yet configured, which systems have no owner, where the knowledge gaps sit, and what the next phase would involve. That list is the plan, and it is more useful after the first phase than before it since it is written from experience instead of estimate.

A phase that delivers records without owners has delivered half of what it should. An obligation with nobody assigned to it is an obligation nobody performs, and the platform will show it as unassigned indefinitely.

Naming owners is an organisational decision and not a technical one, and it belongs with leadership. The platform surfaces where ownership is missing and it cannot decide who should hold it.

Companies find this step harder than the technical work, because it requires somebody to accept responsibility for something they may not have known was theirs. Doing it during a phase, with the scope of the responsibility clear, is easier than doing it during an incident.

After the first area, the sequence tends to follow dependency and not preference. Purposes and notices need the inventory. Consent needs purposes. Retention needs purposes and the inventory. Rights requests need the inventory and benefit from connections to systems.

Breach readiness can proceed in parallel, since it rests on logging and on a response plan more than on the other areas. Processor oversight can also proceed in parallel, since it depends on procurement and contracts instead of the internal configuration.

Evidence accumulates throughout instead of forming a phase of its own. Each area brought into the platform starts producing records as it operates, and a company that has run three areas for six months has evidence covering those three areas without having done anything separately to produce it.

A phased approach carries one risk. The first phase completes and the second never starts. The people who contributed return to their other work, the platform runs for the area it covers, and the remaining areas stay where they were.

What prevents that is treating the sequence as a programme with dates instead of a series of separate decisions. Each phase has a start, a scope and an end, and the next one is scheduled before the current one finishes.

The management view helps here as well. A board that can see how many obligations remain outside the platform has a reason to keep the programme moving, and a privacy officer with that figure has a way of asking for the time.

A company preparing for a scoped assessment can shorten it considerably by gathering a few things beforehand. Whatever system list exists, however partial. The current privacy notice and any retention schedule. A list of the outside services the company pays for, which procurement or finance can usually produce.

Access to the people who know how the company works matters more than any document. A system owner, a business owner for a couple of the main services, somebody from technology who understands the architecture, and somebody who handles customer contact.

None of that needs preparing formally. What the assessment needs is an accurate picture, and an accurate picture assembled quickly is worth more than a polished one assembled slowly.

The assessment produces the sequence, the owners, the priority gaps, the technical dependencies and a first phase with a defined scope. From there the work is bounded and the company can state what it is doing and where it has reached.

That position is worth having for its own sake, separate from the compliance benefit. A company able to describe its programme, its sequence and its current stage answers an enterprise customer, a board question or a regulatory enquiry from a position of knowing, and knowing is most of what any of those readers is actually asking about.

The enforcement date is fixed and the work takes as long as it takes. A company that starts with a scoped assessment and a first phase is moving. A company waiting until the position is clear enough to plan properly is likely to still be waiting when the date arrives.

TrustOS is a DPDPA compliance platform developed and operated by Code Colonies Private Limited. It gives privacy, legal, security, technology, operations and audit teams a single system for personal data records, purposes and notices, consent and withdrawal, requests and grievances from individuals, retention and erasure, breach response, processor oversight and compliance evidence. Every obligation is connected to a responsible owner, turned into assigned work, tracked through to completion, and left with the records that an audit or a regulatory response will call for.

The platform can be deployed inside infrastructure that you control, and the agreed scope can include source code handover, environment setup, security configuration, technical documentation, integration support and knowledge transfer. A scoped gap assessment establishes your current position, the responsible teams, the priority gaps, the technical dependencies and a practical order in which to implement.

To see the platform or to discuss your requirements, continue to the product overview or start a gap assessment. To learn more about our consulting and engineering work, visit codecolonies.com. To start a conversation, write to us at consulting@codecolonies.com.