Reviewing Processors and Assessing Impact

A processor under the Digital Personal Data Protection Act 2023 is a party that processes personal data on behalf of a data fiduciary. The payroll provider, the email delivery service, the cloud hosting company, the support desk tool, the analytics platform, the debt collection agency. Each of them holds personal data that belongs to your customers or your staff.

The Act keeps the fiduciary answerable for that data. A company that meets every requirement inside its own systems, and then sends personal data to a vendor with weak protection, has moved the risk and not reduced it. The Rules require terms in processor contracts obliging them to take reasonable security safeguards of their own, and the erasure duty extends to causing processors to erase data as well.

That arrangement has a practical consequence which companies underestimate. Your compliance position is partly determined by parties you do not control, and the only levers you hold are the contract, the assurance you seek, and the record of both.

It also means the processor list is not a procurement document. It belongs to the compliance record, and it has to be as accurate as the inventory of your own systems.

Few companies can produce a complete list of the parties holding their personal data. The reason is the same one that makes the data inventory difficult. Vendors are engaged over years by different people for good reasons, and a central register was never kept.

Two categories are missed almost every time. The first is the small tool adopted by one team, often paid on a card, holding a modest amount of customer or employee data and appearing in no register. Survey platforms, scheduling tools, transcription services and design tools all fall here.

The second is the sub processor, meaning the service your vendor uses. Your data reaches parties you have never assessed and cannot name, and your agreement should require notice before a vendor appoints one. Companies that have not read their agreements on this point usually find the provision missing.

TrustOS holds the processor record alongside the systems and data categories it touches, which turns the list into something connected instead of a spreadsheet kept separately. A processor holding a sensitive category can be identified as such, and an erasure reaching that category knows which processors to instruct.

A processor record in TrustOS carries the party name, what they do for you, the personal data categories they hold, the systems they connect to or receive data from, the contract and its status, the person inside your company who owns the relationship, and the date of the last review.

The owner field is the one companies leave blank and later regret. A vendor relationship with no internal owner is a relationship nobody reviews, nobody renegotiates and nobody thinks about when the contract renews automatically. Naming somebody is a short decision with a long effect.

The contract status field records whether adequate terms exist, and adequate means specific things and not a general impression. Whether the processor is obliged to take security safeguards, whether it processes only on your instructions and only for the agreed purpose, whether it will notify you of a breach quickly enough for you to meet your own duty, whether it will delete data when instructed and confirm that it has, and whether it needs your agreement before appointing a sub processor.

Recording those five points individually, and not as a single yes or no, is what makes the record useful. A contract can be strong on security and silent on breach notification, and a single field hides that.

Among those contract points, the breach notification term repays the most careful drafting. Your own seventy two hour clock starts when you become aware of a breach, and a breach in a processor system is a breach of data you are responsible for.

If a processor takes a week to tell you about an incident, your position with the Data Protection Board is difficult through no act of your own. A term requiring notification within a short defined period, measured in hours, with a named contact on both sides, protects your reporting position at the moment it matters.

TrustOS records the notification period each contract provides for, so the gap between your obligation and your vendors commitments stays visible instead of surfacing during an incident.

A processor assessed at onboarding and never revisited has been measured against circumstances that no longer apply. The vendor has changed what it does, taken on sub processors, moved data between regions, been acquired, or suffered an incident of its own.

Periodic review answers that, and companies fail to do it consistently because nobody owns it. The privacy team knows it should happen. The relationship owner has other priorities. The review slips a quarter, then a year, and nobody notices because nothing forced the question.

TrustOS creates the review as an assigned action against the processor record, reaching the named owner on a schedule. The review covers whether the data categories are still accurate, whether the contract terms are still adequate, whether any sub processors have been added, and whether the vendor has reported any incidents.

The completion is recorded with a date, which turns a claim that processors are reviewed annually into a list of dates somebody can check.

How deeply to assess a processor is a judgement and not a rule, and treating every vendor alike fails in both directions. Applying heavy assurance to a scheduling tool wastes effort. Accepting a vendor self declaration for a party holding your entire customer database understates the risk.

The factors that determine it are the sensitivity of the data, the volume, and how central the vendor is to your operation. A processor holding health information for a hundred thousand people warrants an independent audit report and possibly your own assessment. A processor holding meeting titles warrants a contract and a look at their published security position.

What matters is deciding that consistently and recording the basis. TrustOS holds the assurance level applied to each processor and the reasoning, so the approach can be explained and applied evenly instead of varying with whoever happened to run the onboarding.

Some processing carries enough risk to the people involved that it warrants a formal assessment before it begins. Processing of sensitive categories, processing at large scale, processing that involves monitoring or automated decisions about people, and new arrangements with processors holding substantial volumes all fall into that territory.

For companies notified as Significant Data Fiduciaries, an impact assessment is an annual obligation and not a discretionary practice. The article on those additional duties in this series covers that requirement in detail.

For everybody else, the assessment works as a tool and not as a filing exercise. It forces a description of what the processing involves, an honest view of what could go wrong for the individuals concerned, and a decision about which controls the processing will operate under.

Recognising that a planned activity falls into this territory is itself a judgement, and it belongs with the privacy and legal function working from the Act and the circumstances.

An assessment that ends in a document has done half its job. It should produce a set of controls the processing will operate under, and those controls become requirements the systems have to meet.

TrustOS holds the assessment against the processing activity it concerns, and turns the resulting controls into assigned actions. A finding that a particular data flow needs encryption becomes work for a technology owner. A finding that a retention period is too long becomes a change to the retention rule. A finding that a processor needs stronger terms becomes a contract action.

That connection stops assessments becoming an archive. Companies with a folder of completed assessments and no record of whether the recommendations were implemented have documented their risks without reducing them.

The assessment also records who approved the processing on the basis of it, and when. That signature matters if the risk later materialises, since it establishes that somebody with authority weighed it.

Processing changes after an assessment is completed. Volumes grow, new fields are collected, a new processor is added, the purpose expands. An assessment describing the processing as it once was describes something that no longer exists.

TrustOS connects the assessment to the processing activity, the data categories and the processors involved, so a change to any of them surfaces as a reason to revisit. A new processor added to a flow assessed last year raises a review action instead of passing unnoticed.

Periodic review handles the slower drift that no single change triggers. Where an assessment is more than a year old and the processing is still running, a review reaches the owner asking whether the description still holds.

Two other areas of the platform depend on the processor record being accurate. When an erasure action runs, it has to reach the processors holding that data category, and it can only reach the ones recorded. When an access request is answered, the response has to name the processors the data has been shared with, and it can only name the ones on the list.

That dependency deserves a plain statement, because it changes how a company should treat this area. An incomplete processor list produces incomplete erasures and inaccurate responses to individuals, and the individual can see both of those failures.

TrustOS creates the processor instruction as an action and tracks the confirmation coming back, so a company knows which vendors confirmed a deletion and which did not. A processor that consistently fails to confirm is a risk worth raising at the next contract review, and the record shows the pattern.

A breach in a processor system is a breach of data you are responsible for, and your reporting clock starts when you learn of it. The processor record therefore belongs in breach response as much as in procurement.

When an incident involves a processor, TrustOS holds the processor record against the incident, along with the notification terms their contract provides for. That gives the people handling the incident the contact route and the contractual position in the same place as the facts.

It also supports the report to the Board, which has to describe the circumstances and the remedial measures. Where a processor caused or contributed to an incident, the report will say so, and the record of what their contract required is part of establishing what went wrong.

A company operating this way can answer a specific question about any vendor without preparation. What data they hold, which systems they touch, what their contract requires, when it was last reviewed, what assurance was sought and why, whether they confirmed the last deletion instruction, and whether they have reported any incidents.

It can also answer the question in reverse. For a given category of personal data, which outside parties hold it. An enterprise customer asks exactly that during a security review, and a regulator asks it when data has travelled further than a notice described.

The management view adds a third. How many processors have no owner, no adequate contract terms, or no review in the last year. Those counts turn vendor oversight from a general concern into a list of specific items to fix.

The first step is the list, and the first version will be incomplete. Ask each team what outside services they use, enumerate the outbound data flows from your applications, and check payment records for recurring charges to software vendors. The three approaches together find most of what a single approach misses.

From there, work in order of exposure. The processors holding the most sensitive categories and the largest volumes get their contracts reviewed and their owners named first. The scheduling tool can wait a quarter.

Renegotiating agreements depends on counterparties and takes calendar time nobody can compress, so this workstream repays an early start. A company beginning contract work six weeks before an enforcement date will not finish it, and the position is visible in the record either way.

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.