What a professional search audit should record, and why

An audit log is written for a reader who does not exist yet. At the moment a search is run, nobody is asking about it. The value of the record only appears later, when a complaint arrives, a supervisor reviews a file, a licensing authority asks a question, or a data provider audits how their licensed information has been used. By then the person who ran the search may have left, the matter may be closed, and memory is worth very little.

That is the test to apply to any search log: if the person who ran this search is unavailable and the file is two years old, does the record on its own answer what was done and why? Most search logs fail that test, not because they record nothing, but because they record the wrong things.

What a defensible record contains

1. The user, individually identified

A shared account is not an audit trail. If three collectors and a team leader share one login, the log identifies an organisation rather than a person, and every question about a specific search becomes a question about who was at the desk. Accounts issued to named, verified individuals are the precondition for everything else in the record. Where a contractor works a single file, they should hold their own account with their own reach rather than borrow someone else's.

2. The authorised purpose, declared before results are returned

This is the entry that carries the most weight and the one most often missing. The Privacy Act 2020 requires that personal information is collected for a lawful purpose connected with a function or activity of the agency, and that collection is necessary for that purpose. The log should therefore capture a stated purpose rather than a category code. "Debt recovery" is a category. "Locating the debtor on account 41822 for service of a statutory demand" is a purpose, and it can be tested against what was actually searched.

The sequencing matters as much as the content. A purpose captured after results are displayed is a rationalisation written by someone who has already seen the answer. intelID binds the declaration to the query and stores it with the query, which is the pattern described on the authorised-purpose controls page.

3. The subject or identifier searched

The log should show what was searched, not only that something was. A name, a company number, a title reference, a phone number or an address is what allows a later reviewer to confirm the search was proportionate to the declared purpose. This is also where scope creep becomes visible: a purpose stated as locating one debtor, with searches run against three family members at the same address, is a pattern that a record will show and a memory will not.

4. The sources queried

Different sources carry different obligations. Credit reporting information sits under the Credit Reporting Privacy Code 2020, which restricts both access and subsequent use. Public register data from the Companies Office, Land Information New Zealand or the Personal Property Securities Register does not. If the log does not distinguish which sources were read, nobody can later tell whether a restricted source was touched on a purpose that did not support it.

5. The timestamp, and the matter reference

The time establishes sequence, which is often the point in dispute: whether the search preceded a decision or followed it, and whether an enquiry was made while a purpose was still live. The matter or file reference is what connects an isolated search to the work it belonged to, and it is the single field most likely to be omitted when a platform is designed around searches rather than around files.

What a log should not become

There is a temptation to store everything, including complete result sets, on the theory that more record is always safer. It is not. Information Privacy Principle 9 requires that personal information is not held for longer than it is required for the purpose for which it may lawfully be used, so a permanent archive of every credit file and title ever returned creates an obligation rather than a protection. Retention should follow purpose: the record of the enquiry is kept long enough to answer questions about the enquiry, and the subject data returned by it is not treated as a private database to be mined later.

Nor should a log be editable by the person it describes. If a user can amend the purpose recorded against their own search, the record proves only that the platform allowed it to be changed. Immutability to the creating user is what turns a log into evidence.

How the record gets used

In practice the record is read in four situations. A supervisor reviewing a file wants to confirm that the enquiry matched the instruction. A licensing authority or professional body wants to confirm that a licence holder worked inside their authority. The Office of the Privacy Commissioner responding to a complaint wants to see what was collected and on what basis. A court considering an application that relies on evidence of reasonable enquiry wants a dated list of what was searched and what each source returned.

Each of those readers wants the same thing: a contemporaneous record made by the system rather than a reconstruction made by the person being asked about it. That is the argument for the audit record being a product of the search itself rather than a report someone remembers to generate. How intelID handles it is set out on the search audit logs page, and the statutory framing on the compliance page.

Applying this in your own practice

If you are assessing a search tool, or your own current process, four questions separate a defensible record from a partial one. Are accounts individual? Is the purpose captured before results are shown, in words rather than a code? Are the specific sources recorded? And can the user who ran the search change any of it afterwards? A process that answers those four well will survive most reviews. One that does not will require someone to remember, and memory is not evidence.

Investigation practices working to licence conditions will find more detail on the private investigators page, and compliance functions on the corporate and compliance page. Access to intelID is issued to verified professional users through the request access page.