Reviewing processors and assessing impact

A hospital and its eleven vendors

A 300 bed hospital in Indore starts its DPDP work by asking each department which outside services hold patient or staff data. IT lists the hospital information system vendor and the cloud host. Finance adds the billing BPO and the payroll provider. Then the surprises arrive. The radiology team uses a transcription service for reports. The front desk sends appointment reminders through a WhatsApp messaging vendor. Marketing ran a patient feedback survey on a tool someone paid for with a company card. The lab system vendor also uses its own subcontractor for backups.

The final list has eleven names. The hospital's contracts register had four.

Why your vendors sit inside your duties

Duties follow the data

Under the Digital Personal Data Protection Act, 2023, a Data Processor handles personal data on behalf of a Data Fiduciary. The payroll provider, the email platform, the cloud host, the support desk tool, the analytics service and the collection agency are all processors for the data you hand them, and that data belongs to your customers or your staff. You remain answerable for it. 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 somewhere else and kept the liability.

The DPDP Rules, 2025 make this concrete in a few places:

• Contracts. Rule 6 lists contract terms with processors among the reasonable security safeguards. The processor has to protect the data properly too.
• Erasure. When data has to be erased, your duty extends to having your processors erase it.
• Breaches. A breach at a processor is a breach of data you are responsible for. You still have to inform affected Data Principals and the Data Protection Board without delay, with a detailed report to the Board within 72 hours of becoming aware.

Failing to take reasonable security safeguards can draw a penalty of up to 250 crore rupees, with the Board deciding the actual amount. The DPDP Rules, 2025 were notified on 13 November 2025, and most of these duties apply from around 13 May 2027; check for later amendments.

The practical consequence is easy to underestimate. Your compliance position is partly set by parties you do not control, and your only levers are the contract, the assurance you seek, and the record of both. That makes the processor list part of the compliance record, and it has to be as accurate as the inventory of your own systems.

Building a list you can trust

Few companies can produce a complete list of the parties holding their personal data, for the same reason the data inventory is hard: vendors are engaged over years, by different people, for good reasons, and nobody kept a central register. Ask in three different ways, because each one catches what the others miss:

1. Ask every team what outside services they use and what data goes there.
2. Trace the data flows out of your main applications: APIs, file exports, email integrations, scheduled uploads.
3. Check the payments. Recurring charges on company cards and in accounts payable reveal the small tools nobody registered.

Two kinds of processor are most often missed. The first is the small tool adopted by one team, such as a survey form, a scheduling app or a transcription service, holding a modest amount of data and appearing in no register. The second is the sub-processor, meaning the vendor your vendor uses. Your data reaches parties you have never assessed and cannot name. Your agreements should require the vendor to tell you before they bring one in, and companies that check usually find that clause missing.

What each processor record should hold

The fields that matter

For each processor, keep:

• what they do for you and which categories of personal data they hold
• which of your systems send them data
• the contract and its status
• a named owner inside your organisation
• the date of the last review and the level of assurance you sought

The owner field is the one teams leave blank and later regret. A vendor with no internal owner never gets reviewed, never gets renegotiated, and renews automatically every year. Naming someone is a short decision with a long effect.

Record contract terms one by one, because a contract can be strong on security and silent on breach notice, and a single yes or no field hides that. Check whether the processor:

• must keep reasonable security safeguards
• processes only on your instructions and for the agreed purpose
• will tell you about a breach within a short, defined period
• will erase data when instructed and confirm it
• needs your approval before appointing a sub-processor

The breach notice term needs the most care

Your own 72 hour clock starts when you become aware of a breach, and a breach in a processor's system is a breach of data you are responsible for. If a vendor takes a week to tell you, your position with the Data Protection Board becomes difficult through no act of your own. A term requiring notice within hours, with named contacts on both sides, protects your reporting position at the moment it matters. For vendors holding sensitive data, fix this term first.

Reviews on a schedule

Why one assessment at onboarding is not enough

A vendor assessed at onboarding and never again has been measured against a situation that has changed. They may have added sub-processors, moved data between regions, been acquired or had an incident of their own.

Reviews slip because nobody owns them. The privacy team knows the review should happen, the vendor owner has other priorities, and it slides a quarter, then a year, with nobody noticing. Put each review on a calendar against the vendor owner, and cover the same points every time: whether the data categories are still right, whether the contract terms are still adequate, whether there are new sub-processors, and whether there have been any incidents. Record the completion with a date. A claim that vendors are reviewed every year becomes a list of dates someone can check.

Deciding how much assurance to seek

Treating every vendor alike fails in both directions. Heavy assurance on a scheduling tool wastes effort. Accepting a self-declaration from the vendor holding your whole customer database understates the risk.

Match the depth of review to the sensitivity of the data, the volume, and how central the vendor is to your operation. The vendor holding a hundred thousand patient records deserves an independent audit report and possibly your own assessment. The tool holding meeting titles needs a contract and a look at its published security information. Write down the level you chose and why, so the next person applies the same standard and the approach does not depend on who ran the onboarding.

Impact assessments that change something

When an assessment is called for

Some processing carries enough risk that it deserves a proper look before it starts: health or financial data at scale, monitoring people, automated decisions about them, or a new vendor taking a large volume of sensitive records. For a Significant Data Fiduciary, a Data Protection Impact Assessment is a yearly duty under the Rules, covered in the guide on meeting Significant Data Fiduciary obligations. For everyone else it is a sensible working tool, and deciding that a planned activity needs one is a judgement for your privacy and legal team.

What the assessment produces

A useful assessment does four things: describes the processing, weighs honestly what could go wrong for the people involved, chooses controls, and records who approved going ahead and when. That approval matters if the risk later materialises, because it shows that someone with authority weighed it.

The controls are the point. An assessment that ends as a PDF has done half its job. A folder of completed assessments with no record of whether the recommendations were carried out documents your risks without reducing them. Each control should become a requirement your systems have to meet, with an owner.

Keeping assessments current

Processing changes after the assessment is done. Volumes grow, a new field is collected, a new processor joins the flow, the purpose widens. The assessment then describes something that no longer exists. Any of those changes should prompt a review, and anything older than a year that is still running should get one anyway.

Where this connects to the rest

Erasure and requests reaching processors

Two other areas depend on the processor list being accurate. When an erasure runs, it has to reach every processor holding that data category, and it can only reach the ones you recorded. When a Data Principal asks for a summary of their data, the Act entitles them to the identities of the processors it has been shared with, and you can only name the ones on your list. An incomplete list produces incomplete erasures and inaccurate answers, and the person on the other end can see both.

Breach response and processors

Because your clock starts when you learn of a processor's breach, the processor record belongs in breach response as much as in procurement. The people handling an incident need the vendor's contact route and contract position next to the facts. The detailed report to the Board has to describe the circumstances and the remedial steps, and where a vendor caused or contributed to the incident, what its contract required is part of establishing what went wrong.

Where TrustOS fits

TrustOS keeps each processor record linked to the systems and data categories it touches. When an erasure runs for a category, it knows which processors to instruct, creates an action for each one and tracks the confirmation. A vendor that keeps failing to confirm shows up as a pattern you can raise at renewal.

Reviews are scheduled actions that reach the named owner. Contract terms, including the breach notice period each contract allows, are recorded point by point, so the gap between your 72 hour duty and a vendor's commitment is visible before an incident. When an incident involves a processor, its record and contract position sit with the incident.

Impact assessments are held against the processing they cover, and each control becomes assigned work: encryption for a data flow goes to the technology owner, a shorter retention period goes to the retention rule, stronger terms go to the vendor owner. When a new processor is added to a flow assessed last year, a review action is raised. Whether a vendor's terms are adequate, or whether processing needs an assessment, is still a judgement for your privacy and legal team.

A company working this way can answer, for any vendor, what data they hold, what their contract requires, when they were last reviewed and whether they confirmed the last deletion. It can answer in reverse which outside parties hold a given category of data, which is exactly what enterprise customers ask in security reviews. And the management view shows how many processors have no owner, no adequate terms or no review in the past year, which turns vendor oversight into a list of specific items to fix.

Where to start

The first version of the list will be incomplete. Build it three ways, then work in order of exposure: the vendors holding the most sensitive data and the largest volumes get owners named and contracts reviewed first. The scheduling tool can wait a quarter.

• Build the processor list three ways: ask teams, trace flows, check payments.
• Name an owner for every processor.
• Record the five key contract terms separately for each one.
• Fix the breach notice term first for vendors holding sensitive data.
• Schedule reviews and scale their depth to the risk.
• Assess high risk processing before it starts and track each control to completion.

Start contract renegotiation early. It depends on the other side's calendar, and a company beginning six weeks before the duties apply will not finish. The Processors and assessments module shows how vendor records, reviews and assessments fit together.