Running TrustOS on Your Own Infrastructure

A platform that manages personal data records, rights requests, consent decisions and breach details is itself holding personal data. Names, contact details, request contents, identity verification records and incident information all sit inside it.

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

A company using a hosted compliance service has added a processor to its arrangements. That processor needs a contract with the terms the Rules require, it needs assessing, it appears in the data inventory, and its handling of the data forms part of the company own position.

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, and an answer naming a third country and an outside supplier invites a longer conversation than an answer naming your own environment.

None of that is a reason against hosted software, and it is a reason to make the choice deliberately instead of by default. TrustOS can be deployed inside infrastructure the client controls, which removes the processor relationship for the platform itself.

When TrustOS runs on infrastructure you control, the personal data inside it stays within your boundary. No transfer has to be described in a notice, no processor agreement has to be negotiated for the platform, and no question arises about what a vendor retains or where it holds it.

For companies with data residency requirements the position is simpler still. Data that has to remain in India remains in India, and the company can demonstrate that from its own infrastructure records instead of a supplier assurance.

The same reasoning applies to sectors carrying regulatory overlays beyond the Act. Banks, insurers and healthcare providers frequently operate under rules from their own regulator about where data sits and who may access it, and a platform inside their own environment sits inside those arrangements automatically.

It also changes the security question. The platform is protected by the controls the company already operates, monitored by its own tooling, and covered by its existing access management instead of a separate set of arrangements with an outside party.

A client controlled deployment is an engagement and not a download, and the agreed scope can include several elements that together leave the company able to operate the platform.

Environment setup covers standing the platform up inside the client infrastructure, with the databases, application services, storage and networking it requires. Security configuration covers access control, encryption, logging and the settings that align the deployment with the company own standards.

Integration support covers connecting the platform to the systems the company runs, and the previous article in this series describes that work. Technical documentation covers how the deployment is put together, how it is operated, and what somebody maintaining it needs to know.

Knowledge transfer covers the sessions that leave the client team able to run the platform without depending on the supplier for routine operation. That element is the one companies most often shorten and most often regret, because a platform nobody internally understands becomes a dependency.

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

With the code, the company can inspect what the platform does with its data, satisfy a security review that asks to see it, make changes if its own requirements move beyond what the platform provides, and continue operating the platform independently of any commercial relationship.

Without it, the company holds a running system it cannot examine or modify. That position is normal for purchased software and it differs from ownership, so companies evaluating the platform should be clear about which one they are buying.

Holding the code carries an obligation alongside the benefit. Somebody inside the company needs to understand what they hold well enough to maintain it, and that is the reason knowledge transfer sits in the same scope.

Running software inside your own infrastructure means running it. The platform needs the ordinary attention any business system requires, and a company deciding on this deployment should count that cost honestly.

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. It needs backups that somebody has actually restored, since a compliance platform holding a year of evidence is a poor place to discover that the backup was never tested.

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 and does not replace a person who has worked with the system. Naming that person, and making sure a second person could stand in, is the practical form of the knowledge transfer the scope includes.

It needs capacity planning as the volume of records grows, and it needs the access to it managed as people join and leave. None of this is unusual, and all of it belongs to the company and not to a supplier.

A company already operating its own systems absorbs this into existing practice. A company that runs everything as a service will find this the largest change, and the honest answer for such a company may be that hosted deployment suits it despite the processor relationship.

Client controlled deployment does not mean the supplier disappears. Support arrangements can cover updates to the platform itself, assistance with integrations, help when something behaves unexpectedly, and guidance as the regulatory position develops.

What changes is the nature of the relationship. The supplier helps the company run something the company holds, instead of running it on the company behalf. The data stays inside the company boundary throughout, and access for support purposes is granted by the company on its 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 are all questions with straightforward answers when they are agreed before anybody needs them.

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

Companies frequently miss this, and the omission is visible to an auditor immediately. An inventory listing every business system while leaving out the compliance platform suggests the inventory was assembled by somebody working from a list of applications instead of from a question about where personal data sits.

The entry records what the platform holds, who owns it, what its retention rules are and who has access. Rights requests reach it, because an individual asking what data a company holds about them is asking about the platform records too.

Retention applies as well. Request records, consent histories and incident files all have periods after which they are no longer needed, subject to any longer statutory requirement. A platform accumulating records indefinitely does to itself what it exists to prevent elsewhere.

The measures Rule 6 requires 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, retained for a year. Backups that support continued processing if data is lost.

A deployment inside the company infrastructure makes those measures easier to satisfy, since the company applies its existing controls instead of assessing somebody else. It also makes them the company responsibility, which they were in any case.

The article on Significant Data Fiduciary duties in this series covers the additional requirements that apply to notified companies, and the platform sits inside those as well.

A company choosing between client controlled and hosted deployment can settle the question with a short set of questions asked honestly.

Does the company have data residency requirements, from the Act, from a sector regulator or from its own customers. Does it have an engineering function able to operate another system. Does it hold personal data sensitive enough that adding a processor is a decision requiring justification. Does it sell to customers who examine its supplier arrangements. Is it likely to be notified as a Significant Data Fiduciary.

Several yes answers point toward client controlled deployment. Several no answers point the other way, and a company in that position should not take on infrastructure it will struggle to maintain merely because ownership sounds preferable.

The wrong answer here produces a platform that is poorly maintained inside a company boundary, and that is worse than a well maintained platform outside it.

The case for holding the platform strengthens over the years instead of at the start. A compliance platform accumulates the record of everything a company has done, and that record becomes the company account of its own compliance history.

Holding that inside your own infrastructure means it stays available regardless of what happens to any commercial relationship. A supplier that changes its terms, is acquired, or ceases 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 residency and processor points matter at the start, and the continuity point matters for as long as the records do.

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.