What privacy software can prove, and what still needs judgment

Imagine a dashboard showing every task in green. A report says all connected systems have completed deletion. A consent log contains a timestamp for each account. These outputs can be useful evidence. They do not answer every question about whether the underlying processing was lawful, complete or fair to the person involved.

The practical question is what a particular record proves. A timestamp may demonstrate that an event was recorded by a system at a particular time. It does not, without context, establish that the customer understood the purpose or had a valid choice.

As at 22 October 2026, the relevant substantive DPDP duties are scheduled to commence on 13 May 2027 under the commencement notification. This makes evidence design a readiness task. It is not a basis for claiming a product guarantees compliance with duties that require legal and operational judgment.

Separate the event from the conclusion

Section 6(1) sets conditions for consent, including that it be free, specific, informed, unconditional and unambiguous, with a clear affirmative action. Section 6(10) places the burden on the fiduciary to prove notice and consent in the relevant proceeding when a question arises.

A useful consent record could connect a person’s action to the notice version, purpose, collection channel and subsequent changes. The precise evidence design depends on the system. The Act does not prescribe one universal ledger schema or make a blockchain entry conclusive proof of valid consent.

Consider a hypothetical booking app. Its log accurately records a checked box, but the screen made optional marketing appear necessary to complete a booking. The log supports the fact of the recorded interaction. Reviewing the screen and journey is still necessary to assess the quality of the choice.

Ask what the system could not see

A deletion tool can report success for the services it actually contacted. If a support team exported customer data into an unmanaged folder, the report may say nothing about that copy. Coverage is part of the evidence, not a small implementation detail.

For a hypothetical deletion exercise, record the systems in scope, identifiers used to find records, actions requested, responses received and unresolved exceptions. Distinguish a request accepted by a service from completion verified in that service. Describe any delay or legal retention decision accurately.

A status that says “complete” should have a defined meaning. If it means all configured connectors responded, explain that scope. Do not silently translate it into a claim that no personal data exists anywhere in the business.

Keep legal decisions visible

Software can apply a configured retention rule. Someone still needs to determine why that rule is appropriate for the relevant purpose and applicable laws. A tool can route a rights request. Someone still needs to evaluate identity, scope, competing interests and justified exceptions.

The fiduciary’s responsibility under section 8(1) continues for processing undertaken on its behalf. Buying a service or signing a processor agreement does not move all accountability to the supplier. Useful procurement questions therefore concern both technical behaviour and who makes decisions when facts do not fit the standard workflow.

Require an explanation for overrides and unresolved cases. The objective is not to prohibit judgment; it is to make judgment reviewable. A carefully recorded exception may be more informative than a forced green status hiding a known limitation.

Test claims with a bounded scenario

Before relying on a product, choose one realistic synthetic example. For the booking app, create a test account, present two notice versions, change one optional preference and submit a deletion request. Observe which records connect the sequence and which systems receive the resulting instructions.

Then introduce a known failure, such as a disconnected test service or an unmatched identifier. Can the tool distinguish incomplete work from success? Can an authorised operator investigate the problem without exposing unrelated customer data? These are suggested evaluation exercises, not claims about any particular product’s capabilities.

Rule 6 addresses technical and organisational security safeguards. A product demonstration should therefore sit alongside review of access, monitoring, contracts, recovery and staff responsibilities. A single feature cannot establish the whole security position.

Make the report honest enough to use

A useful evidence pack states the period, systems, configuration, sample method and exceptions. It links important conclusions to records someone can inspect. It avoids unsupported claims that a score, certification badge or automation rate proves universal legal compliance.

For SWARN or any other developing product, distinguish proposed capabilities from verified available behaviour. Do not present planned integrations or a design mock-up as a deployed control. The failure to avoid is turning evidence into theatre: keep the record precise, expose its limits and assign the decisions that the software cannot responsibly make on its own.