Your accounts. Your files. Your workflow.

Stage-by-stage policy

1. Public website and fit-check stage

The public website is designed to qualify a reporting problem without receiving the report itself. The fit-check form asks for a name, work email, organisation, report frequency, format, high-level input description, approximate production time, primary problem, sensitive-data screening answer and a non-confidential workflow summary.

• No public file upload: the site does not offer an attachment field.
• No credentials: do not submit passwords, tokens, links that grant access or recovery information.
• No client content: do not paste client names, source figures, contract terms or confidential narrative.
• No unnecessary tracking: the launch site uses an essential session cookie for form security and does not enable advertising pixels by default.

Fit-check submissions may be sent by email to the business and saved in a protected server-side backup so an enquiry is not lost if email delivery is delayed. The configured retention period is documented in the website configuration and should be reviewed regularly.

2. Diagnostic stage

After the fit check, a suitable prospect may purchase the Report Workflow Diagnostic. Before any current report or sample data is requested, Client Report Works confirms:

• the organisation has authority to share and process the material;
• the report and data fall inside the agreed launch boundary;
• the minimum evidence needed to assess feasibility;
• the transfer method, storage location and people permitted to access it;
• whether anonymised, redacted, synthetic or reduced samples can be used;
• the intended retention and deletion point.

Health, student and highly sensitive personal information, and regulated tax, investment or clinical calculations, are outside the standard launch scope. A request may be declined or referred to a provider with the necessary specialist controls.

3. Project access

Where practical, work is carried out in accounts, folders or environments controlled by the client. Access should be:

• granted to named people rather than shared identities;
• limited to the least privilege needed for the approved task;
• protected with multi-factor authentication;
• recorded and removed when the task or engagement ends;
• kept separate from public demonstration or marketing material.

Credentials should not be emailed in plain text. The agreed project method may use delegated access, a password manager, a client-created temporary account, a secure upload location or an equivalent controlled approach.

4. Tools, contractors and AI

The technical method is chosen after the outcome and control requirements are understood. A workflow may use the client’s existing spreadsheet, document, presentation, dashboard, query or scripting tools.

• Third-party tools: their use, account owner and data role should be visible in the written scope.
• Contractors: a specialist receives only the information and access needed for the approved work and is subject to appropriate confidentiality and handling requirements.
• AI services: confidential client content is not placed into an AI service without written approval and an acceptable data-processing configuration. AI is not assumed to be part of the workflow.
• Client judgement: automation may support drafting or production, but interpretation, professional advice and final client-facing approval remain human responsibilities.

5. Reconciliation and release control

The workflow identifies the source, reporting period, transformation rules, known exceptions, review owner and release status. Depending on the report, the QA checklist may cover:

• source totals and row counts;
• reporting period and source refresh time;
• filters, joins, formula results and unmapped values;
• units, chart ranges, labels and page/export integrity;
• calculated facts versus human commentary;
• named reviewer, approval date and release version.

Automation is not treated as proof of accuracy. The output is released only after the agreed checks and human approval are complete.

6. Retention, deletion and handover

The proposal or statement of work should identify what is retained, where, by whom and until when. At handover:

• the client receives the approved workflow, operating guide, QA checklist and change log;
• project access is reviewed and removed when no longer required;
• temporary copies and raw samples are deleted when their agreed purpose ends;
• any retained support material is limited to what the care or support obligation requires;
• the client is told about any unresolved assumption, exception or dependency.

7. Suspected incidents

A suspected loss, unauthorised access, incorrect disclosure or material integrity problem should be contained, recorded and assessed promptly. Relevant access may be disabled, affected material preserved for investigation, and the client notified in accordance with the engagement terms and applicable obligations. Client Report Works maintains a named contact for privacy and data-handling questions.

8. Questions or requests

For a question about this data-handling approach, email privacy@clientreportworks.co.nz. For access or correction requests relating to website enquiry information, see the privacy statement.

Last updated 12 August 2026