Running TrustOS on your own infrastructure

The question from the information security committee

An NBFC in Mumbai is choosing a DPDP compliance platform. The privacy team likes what it has seen in the demonstrations. Then the proposal goes to the information security committee, and the first question has nothing to do with features. The committee wants to know where the platform will run, who outside the company can reach it, and whether it will hold customer names, loan account numbers, KYC verification notes and complaint details.

It will hold all of those, and that fact should be settled before anything else is decided. The location of a compliance platform is itself a compliance decision, and the choice between a client controlled deployment of TrustOS and a hosted service shapes what your team takes on.

Why deployment location matters here

A compliance platform holds personal data

A platform that manages personal data records, rights requests, consent decisions and breach details is itself holding personal data. Names, contact details, what people asked for, how their identity was checked, the contents of a complaint and what happened in an incident all sit inside it.

That makes the deployment question different from the one companies ask about ordinary business software. Where a project tracker runs is a commercial and technical choice. Where your compliance platform runs is also a compliance choice, because the platform becomes part of what the company has to account for under the DPDP Act.

If the platform is hosted by a supplier, that supplier becomes a Data Processor for you. It needs a contract with the security terms the DPDP Rules expect, it needs reviewing like any other vendor, it appears in your data inventory and your processor list, and its handling of the data forms part of your own position. None of that is unusual. It is one more relationship to manage, and it should be managed on purpose.

The question comes up most sharply during a security review. An enterprise customer examining your data handling will ask where your compliance records sit and who else can reach them. An answer that names an outside supplier and a hosting arrangement invites a longer conversation than an answer that names your own environment.

Hosted software is a sound choice for many companies. What matters is that the choice is made deliberately. TrustOS can be deployed inside infrastructure you control, which removes the processor relationship for the platform itself, and it can also be hosted. Both are legitimate, and the right one depends on your circumstances.

What client controlled deployment removes

When TrustOS runs on infrastructure you control, the personal data inside it stays within your boundary. There is no processor agreement to negotiate for the platform, no question about what a vendor retains or where it keeps it, and nothing about the platform to describe as sharing with a third party.

For companies with data location requirements the position is simpler still. Data that has to stay in India stays in India, and your own infrastructure records show it, so the evidence is in your hands.

The same reasoning applies to sectors with rules beyond the Act. Banks and NBFCs under the Reserve Bank of India, insurers under IRDAI, hospital groups and government departments often have their own requirements about where data sits and who may reach it. A platform inside their own environment sits inside those arrangements from the start.

It also changes the security question. The platform is protected by the controls the company already runs, watched by its own monitoring, and covered by its existing access management through the identity provider it already uses. There is no separate set of arrangements with an outside party to keep in step.

The safeguards apply either way

Whichever model you choose, the Rule 6 safeguards apply to the platform in the same way as to any other system holding personal data. That means encryption, obfuscation or masking of the data it holds, control over who can reach it, logging and monitoring that can detect unauthorised access, logs and related personal data kept for at least one year so incidents can be detected and investigated, and backups so processing can continue if data is lost. The security safeguards duty carries the highest penalty in the Schedule, up to ₹250 crore.

The DPDP Rules, 2025 were notified on 13 November 2025, and most of these duties apply from the third phase of commencement, around 13 May 2027; check for later amendments. That leaves time to plan the deployment properly, and the decision is best made well before the final quarter.

What the deployment scope covers

The elements of a deployment

Deploying TrustOS inside your environment is an engagement with a defined scope, agreed up front. The scope can include several elements that together leave your team able to operate the platform:

• Environment setup. Standing up the databases, application services, storage and networking inside your cloud account or data centre.
• Security configuration. Access control, encryption, logging and the settings that align the deployment with your own standards and your existing identity provider.
• Integration support. Connecting TrustOS to the systems that hold personal data, so connectors can search, act and confirm through a documented interface or scoped database access.
• Technical documentation. How the deployment is put together, how it is operated, and what somebody maintaining it needs to know.
• Knowledge transfer. Working sessions that leave your team able to run the platform day to day without calling the supplier for routine operation.
• Source code handover, where it is in the agreed scope.

Knowledge transfer is the element teams most often shorten and most often regret. A platform that nobody inside the company understands becomes a dependency of a different kind, and the saving made by cutting a few sessions is lost the first time something behaves unexpectedly.

Source code handover

The agreed scope can include handover of the source code, and that provision changes what you hold at the end of the engagement.

With the code, your team can inspect what the platform does with personal data, show it to a security reviewer who asks to see it, make changes if your requirements move beyond what the product provides, and keep running the platform whatever happens to the commercial relationship.

Without it, you hold a running system you cannot examine or modify. That position is normal for bought software, and it falls short of ownership. A company evaluating the platform should be clear about which of the two it is buying, and should write that into the scope.

Holding the code carries an obligation alongside the benefit. Somebody inside the company needs to understand it well enough to maintain it. That is why knowledge transfer sits in the same scope as the handover, and why the two should not be separated to save time.

What your team takes on

Operating the platform

Running software inside your own infrastructure means running it. The platform needs the ordinary attention any business system needs, and a company choosing this model should count that cost in full before it signs.

It needs somebody to apply updates, including security updates to the platform and to the components beneath it. It needs monitoring, so that a failure is noticed the same day, well before a request goes missing. It needs backups that somebody has actually restored in a test, because a compliance platform holding a year or more of evidence is a poor place to discover that the backup was never checked.

It also needs somebody who knows the deployment well enough to diagnose a problem at nine on a Monday morning. Documentation covers part of that. The rest comes from a person who has worked with the system. Naming that person, and making sure a second person could stand in for them during leave or after a resignation, is the practical form of the knowledge transfer the scope includes.

It needs capacity planning as the volume of records grows over the years, and it needs access managed as people join, move between teams and leave. Your team takes on:

• applying updates, including security updates to the platform and the components under it
• monitoring, so a failure is noticed the same day
• backups that someone has actually restored in a test
• capacity as records grow over the years
• access management as people join, move and leave
• a named person who knows the deployment well, and a second who can stand in

None of this is unusual, and all of it belongs to the company. A company already running its own core systems, such as a bank with its own data centre team or a manufacturer with an in-house ERP group, will absorb this into existing practice. A company that runs everything as a service will find this the largest change, and for that company hosting may suit better despite the processor relationship.

Where support still applies

A client controlled deployment does not mean the supplier disappears. Support arrangements can cover updates to the platform itself, help with integrations, assistance when something behaves unexpectedly, and guidance as the regulatory position develops, for example as later phases of the Rules come into force.

What changes is the nature of the relationship. The supplier now helps you run something you hold, and your own team operates it day to day. The data stays inside your boundary throughout, and any access for support is granted by you on your own terms.

Settling those terms at the start avoids awkwardness later. How support access is granted, what it permits, how it is logged and how it is revoked all have straightforward answers when they are agreed before anybody needs them. Agreed in the middle of an outage, they tend to be settled in a hurry and written down by nobody.

How this connects to the rest of the Act

The platform belongs in its own inventory

A compliance platform holding personal data belongs in the data inventory alongside every other system. That sounds circular, and it is still the correct treatment, because the platform is a system holding personal data and the Act does not exempt it.

Companies often miss this, and an auditor notices straight away. An inventory that lists every business system and leaves out the compliance platform suggests it was put together from a list of applications. A sound inventory starts from the question of where personal data actually sits.

The entry records what the platform holds, who owns it, what its retention rules are and who has access. Rights requests reach it too. If a Data Principal asks what you hold about them, their request records and consent history inside TrustOS are part of the answer.

Retention applies as well. Request files, consent histories and incident records all have periods after which they are no longer needed, subject to any longer legal requirement, such as the one-year minimum for logs under Rule 6 or a sector rule that asks for more. A platform that keeps everything forever does to itself what it exists to prevent elsewhere.

Security safeguards apply to the platform

The measures in Rule 6 apply to the platform in the same terms as to any other system: encryption or masking for the data it holds, control over who can reach it, logging and monitoring able to detect unauthorised access, retention of those logs for at least a year, and backups that support continued processing if data is lost.

A deployment inside your own infrastructure makes those measures easier to satisfy, because the controls are ones you already run and already know how to evidence. It also makes them visibly your responsibility, which they were in any case.

If your company is notified as a Significant Data Fiduciary, the additional duties, such as periodic Data Protection Impact Assessments and audits, cover the platform as well. Those duties carry penalties of up to ₹150 crore, and they are another reason to treat the platform as an ordinary system in your own estate.

Deciding between deployment models

The questions that settle it

A company choosing between client controlled and hosted deployment can usually settle the matter with a short set of questions:

1. Do you have data location requirements from the Act, a sector regulator, your customers or your own policy?
2. Do you have an engineering or infrastructure team that can operate one more system well?
3. Is the personal data sensitive enough that adding a processor needs justification?
4. Do your customers examine your supplier arrangements during security reviews?
5. Are you likely to be notified as a Significant Data Fiduciary?

Several yes answers point towards deploying inside your own environment. Several no answers point towards hosting. The current hosted option keeps client data on servers in India, which answers part of the location question for many companies.

A company with mostly no answers should not take on infrastructure it will struggle to maintain only because ownership sounds better. A platform that is poorly maintained inside your boundary is worse than one that is well run outside it.

Many organisations also start in phases. One area, such as rights requests, goes live first, and the rest follows once the team is comfortable with the deployment and has run a few months of updates and backups.

What ownership is worth over time

The case for holding the platform grows stronger with each year of records. A compliance platform builds up the record of everything a company has done: every request, every consent change, every review and every incident. That record becomes the company's own account of its compliance history.

Holding it inside your own infrastructure means it stays available whatever happens to a commercial relationship. A supplier that changes its terms, is acquired or stops trading does not take the record with it.

For a company that expects to be answering questions about its data handling for years, that continuity is the substantial argument. The location and processor points matter at the start. The continuity point matters for as long as the records do.

A short checklist

• Decide the deployment model with the information security committee, early.
• Agree the scope in writing: environment, security, integrations, documentation, knowledge transfer, and source code if you need it.
• Name the internal owner and a backup person.
• Test a backup restore before go-live, and again on a schedule.
• Apply Rule 6 safeguards to the platform itself, including one-year log retention.
• Add TrustOS to your own data inventory and set its retention rules.
• Agree how support access is granted, logged and revoked.

TrustOS is where the compliance work runs and where its evidence is kept. The judgement and the effort stay with your teams, and where the platform itself runs deserves the same care. Both options are compared on the deployment page.