Connecting TrustOS to the Systems You Already Run

A compliance platform can work in two ways. It can tell a person what needs doing and record what they say they did, or it can reach into the system and do it, then confirm the result.

Companies usually begin in the first mode, since it requires nothing of their systems. Somebody in privacy raises the work, somebody in technology carries it out, and somebody records the outcome. That arrangement functions, and it depends entirely on people reporting accurately and on nobody forgetting a step.

Both have a place, and they produce evidence of different strength. A record stating that an engineer erased a set of records rests on that engineer account. A record produced by the system itself, showing which records were removed and when, rests on the system.

Auditors and regulators know the difference and test for it. Asking how a company proves its retention rules run, and receiving an execution log, ends the question. Receiving a description of the process invites more of them.

Connections are how the platform moves from the first kind of record to the second. Not every system will be connected, and the ones holding the most personal data are the ones where the difference matters most.

A connector is a defined link between TrustOS and one of your systems, operating within permissions you set. Through it the platform can search for personal data relating to an individual, execute an approved action such as an erasure or a correction, and confirm what happened.

What a connector looks like in practice depends on the system. Some expose a documented interface built for exactly this kind of integration. Some require a query against a database with credentials scoped for the purpose. Some offer only a partial route, allowing a search but no execution, and the platform records that limitation instead of working around it.

Those three capabilities map onto the obligations directly. Search supports access requests and breach scoping. Execution supports erasure, correction and retention. Confirmation supports the evidence every one of them requires.

A connector does not give the platform general access to your systems, and the scope is part of the setup. It reaches the data categories and the operations the configuration allows, and nothing beyond that.

Setting up a connector involves a short set of decisions, and making them deliberately at the start avoids reopening them later.

Which system is being connected, and who owns it. Which data categories the connector reaches, since a system may hold personal data alongside a great deal that is not. Which operations are permitted, because a system where erasure is allowed differs from one where the platform may only search. Which credentials the connection uses, and what those credentials are permitted to do inside the system.

The credentials decision deserves attention. A connection running with broad administrative rights can do more than the compliance work requires, and narrowing those rights to the operations actually needed is straightforward at setup and awkward afterwards.

The owner of the system approves the connection and its scope, and TrustOS records that approval with a name and a date. That record answers the question of who authorised the platform to act inside a production system, which somebody will eventually ask.

A connector searching for personal data about an individual needs to know how that individual appears in the system it is reaching. The same person is a customer number in one place, an email address in another, and a national identifier in a third.

Resolving those identities is genuine work, and it is the part of connector setup that companies underestimate. A search that matches on email address alone will miss records where the person used a different address, and a search that matches too loosely will return records belonging to somebody else.

TrustOS holds the identifiers a system uses and how they relate to the individual record, so a search can be constructed properly. Where identity resolution is imperfect, and it often is, the configuration records that limitation instead of hiding it.

Companies with several customer facing systems built at different times usually have the hardest version of this problem. The person exists three times with no shared key between the records, and connecting them requires either a matching exercise or a decision to search each system separately on its own terms.

That honesty matters when a response goes out. A company able to say which systems were searched and on what basis is describing a bounded search. A company that assumed its search was complete is making a claim it cannot support.

Actions that change data pass through approval before a connector executes them. The action reaches the responsible owner with the detail of what would happen, in which system, to which records, under which requirement, and the approval is recorded.

That step exists because erasure and correction cannot be undone. Data due for removal under a retention rule may have become relevant to a legal hold or a live dispute since the rule was set, and approval gives somebody with current knowledge the chance to say so.

Where a legal hold applies, TrustOS records it against the data so the action is suspended with a reason instead of being proposed repeatedly and declined repeatedly.

When a connector executes an action, the platform records what was attempted, what happened and when. A successful execution carries the records affected and the timestamp. A partial execution carries what completed and what did not. A failure carries the reason the system returned.

Recording the partial and failed cases accurately is what makes the whole arrangement trustworthy. An action that removed data from a table and could not remove it from an associated index has done part of the job, and marking it complete would put something untrue into the record.

TrustOS keeps those cases open with the specific gap identified and assigned to somebody. The count of open executions is a useful figure in its own right, because it measures the distance between what the company decided and what its systems actually did.

Executing an action and verifying it are different things, and a platform that treats them as one will overstate its own reliability. A system may accept an instruction, report success, and leave the data in place because of a constraint nobody anticipated.

Where a connector supports it, TrustOS verifies afterwards by checking that the data is genuinely gone or genuinely changed. Where verification is unavailable, the record shows that the action was executed and not independently confirmed, and that is a weaker position stated honestly.

Distinguishing those two states in the record is worth the effort. A company that can separate verified completions from reported ones knows where its own evidence is strong and where it rests on a system word.

Not every system can or should be connected. Older applications may have no interface worth building against. Outside services may offer limited access. Some systems are scheduled for retirement, and connecting them would be effort spent on something that is going away.

Those systems still hold personal data and the obligations still reach them. TrustOS handles them by assigning the action to the system owner with the detail they need, and the owner executes it and records what they did.

That record is weaker evidence than a system confirmation, since it rests on a person statement, and it is far stronger than no record. What matters here is a system that appears in the platform, with its obligations tracked and the work reaching it visible.

Companies frequently find that the unconnected systems are where compliance work has quietly not been happening. Retention rules that run automatically in the main database were never applied to the older application, because applying them required somebody to remember.

Bringing those systems into the assigned action cycle makes the omission visible. That is uncomfortable in the short term and it is the point of the exercise, because an obligation nobody can see is an obligation nobody meets.

It also produces a useful argument for connecting more systems over time. A company that can see how much manual work its unconnected systems generate has the figure it needs to decide whether building a connector is worth it.

Any connection that can search and change personal data is a route into that data, and it deserves the treatment any such route gets. Credentials scoped to the operations needed and no more. Access recorded so that every action taken through the connector is attributable. Regular review of whether the connection is still required.

The Rules require access control and logging as part of reasonable security safeguards, and connectors fall inside that requirement and not beside it. A connection created for compliance work that becomes an unmonitored path into production has created a risk while addressing another one.

TrustOS records every action executed through a connector with the individual who approved it, which means the connector activity is itself part of the audit trail.

Systems change, and a connector built against a system last year may be reaching data that has since moved or operating with permissions that are now broader than needed.

Periodic review of each connector belongs in the same cycle as the other reviews the platform assigns. The system owner confirms that the scope is still right, the permissions are still appropriate, and the connection is still required.

The review also catches scope that has widened without anybody deciding to widen it. A system that gained a new table holding personal data may now be within the connector reach without the configuration recording that category, which leaves the platform searching data nobody registered.

Retiring a connector when a system is decommissioned is the part most often forgotten. A credential left active against a system nobody uses is exactly the kind of dormant access that security reviews look for.

Connecting everything at once is neither achievable nor sensible. The sequence that works balances how much personal data a system holds against how much effort the connection takes.

The systems holding the largest volumes of the most sensitive categories come first, because that is where a manual process is slowest and where an incomplete search does the most damage. Systems with modern interfaces come before older ones, since the effort is lower and the platform starts producing verified evidence sooner.

Systems scheduled for retirement are left alone. Systems holding little personal data can wait, and the assigned action route covers them adequately in the meantime.

The first connected system changes what the platform can demonstrate. Retention actions that previously depended on somebody confirming they had run now produce execution records. Searches for an access request return results directly instead of waiting for a person to look.

That shift is visible to the people doing the work, which matters for whether the platform gets used. An engineer who no longer receives ad hoc requests to check whether a customer exists in a database will notice.

It is also visible to an auditor, and companies preparing for an independent audit usually find that connecting the two or three systems carrying the most obligation weight improves their position more than any amount of additional documentation.

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.