Moving Food Safety Records to an App NZ: Keep the Evidence Usable

Moving food safety records to an app is a change in how people capture and retrieve evidence. It should not quietly change what they check, remove the context around a result or make earlier records inaccessible. A tidy dashboard can still hide a gap between the registered requirements and the work being recorded.

This guide helps New Zealand food businesses plan a controlled move from paper or another system. It focuses on the food-safety workflow and evidence. It is not a software comparison, a technical installation manual or a statement that an app has regulatory approval.

Food safety records in an app: start with the requirements

Identify the business’s current plan or programme and the activities that apply. Build the move around that source, rather than assuming the app’s standard checklist covers your operation. Food Control Plans, National Programmes and other regulatory pathways should not be treated as one identical record list.

MPI’s February 2026 record templates allow businesses to use the supplied forms, adapt them or create their own, while recording the correct information. The document directs users to the current plan’s recording requirements. Its format flexibility is not permission to change an applicable food-safety control.

MPI’s Simply Safe and Suitable record-keeping guidance includes electronic storage ideas and explains that records need to show what happened, when and who did it, with accurate, readable information available for review. The National Programme 1 guidance also discusses electronic records. Apply the source relevant to your operation; none of these documents is an endorsement of a particular commercial app.

The practical steps below are AFVA recommendations for managing the transition, not a mandatory national migration procedure. If the proposed change also alters your activities, process, limits or registered plan, assess those changes separately through the applicable process.

Map each record’s information and meaning

Choose a small set of representative completed records and walk through what each field means. Include a routine satisfactory entry, an exception and a record linked to another document. Use suitable redacted examples when working with a provider; do not send unnecessary personal or commercially sensitive information.

For every record type, identify the activity, applicable instruction, product or equipment, actual observation, event date/time where needed, person performing the task, response to a problem and review. These are suggested mapping questions, not a claim that every record requires every field.

Ask about differences between a measured value, a target, a yes/no answer and a calculated status. A “complete” tick may mean that a form was submitted; it does not necessarily mean a control was satisfactory or an exception was resolved. Agree the meanings users will rely on.

Decide where historical evidence will remain

You do not need to turn every old page into a newly typed app entry merely to make the dashboard look continuous. First decide what history needs retention and how authorised people will retrieve it. A controlled paper archive, retained digital files and imported data may have different roles in the agreed arrangement.

Create a concise index connecting each historical period and record type to its location. Identify where completed pages, attachments, investigation notes and relevant previous versions remain. Keep originals or reliable retained copies available under the requirements applying to your business. Do not delete old records simply because a subscription or platform changes.

Where information is imported, test the result against the source. Check dates, time formats, units, names or user identifiers, lot references, attachments and visible text. Record what was transferred, what stayed in the archive and what could not be transferred. Preserve limitations instead of filling gaps with assumed values.

For a genuine mistake or missed historical check, use the separate food safety record-correction guide. This transition article does not authorise backdating, inventing measurements or silently replacing a failed result. For obsolete blank forms and instructions, the document-control guide addresses withdrawing working copies while preserving history.

Test the daily workflow on the devices staff use

Run a practical trial with the people who perform the checks, on the phones or tablets they will actually use and in an appropriate place. A manager completing a demonstration on an office computer does not establish that the production team can follow the same process during work.

Ask staff to find the right task, identify the food or equipment, enter the genuine information and record an exception. Check whether labels, units, instructions and confirmation messages are understandable. Consider shift changes, language needs, access permissions and who helps when the normal user is absent.

Use the food business’s hygiene and device-use arrangements. Do not create a new handling or contamination problem just to enter a record. The appropriate device location and working method depend on the operation; this guide does not require staff to handle a screen while handling food.

Check whether reminders are useful, but keep them separate from evidence. A reminder is a prompt to carry out work. It is not proof that the task occurred, and an automatically filled field should not be mistaken for an observed result. Train staff on those distinctions before relying on the new records.

Test corrections, missed tasks and interruptions

Include situations where the process does not run smoothly. Ask the provider to demonstrate what happens when a user submits the wrong value, misses a task, loses connection or discovers that an attachment did not upload. Do not assume the product supports offline entry, an audit trail or automatic recovery unless that function has actually been demonstrated and suits the requirement.

Agree how an authorised correction preserves the original information and the actual amendment details. Keep the date of the event separate from the date of later entry or correction. Check whether exported records retain enough of that history for the intended review.

For a missed task or adverse result, follow the business’s actual food-safety response. A software status must not prevent the responsible person from assessing affected food, recording action or making a required escalation. Keep “not done”, “done with a problem” and “review completed” distinguishable.

Prepare a practical fallback for an unavailable device or service. Identify the approved temporary record method, responsible person and later reconciliation process. If information is entered later, preserve when the activity actually occurred and what evidence supports it. A later synchronisation or upload time should not disguise an earlier gap.

Prove that records, exports and recovery are usable

Ask an authorised person who did not build the system to retrieve a chosen date, activity and related exception. Include a deputy and any relevant site or shift. Check access to older records and attachments, rather than demonstrating only today’s dashboard.

Test the proposed review or export pack. Can the recipient read the entries, identify the people and events, follow the supporting links and see the relevant correction or action history? Check what is omitted. A PDF summary, spreadsheet export and platform view may contain different information; agree which combination meets the actual need.

Discuss access for verification without assuming the verifier needs a permanent account or unrestricted access to all business information. Agree a usable arrangement appropriate to the review. Confirm that retained evidence will remain available if the business changes providers or the employee holding the account leaves.

Ask the provider what backup, recovery and export functions it actually supplies, what the business is responsible for and what happens when the service ends. Test the relevant retrieval or recovery process using a safe example. A statement that records are “in the cloud” is not a demonstrated recovery result.

If the system also holds batch links, preserve the connections described in the food batch-coding and traceability guide. Exporting a list of finished codes without the related receipts, production or dispatch references may leave the evidence difficult to follow.

Make the switch with a clear boundary and review

Name the responsible person, the records covered and the date or event at which the new working method starts. Explain where earlier records remain. If there is a trial period with two methods, identify which is authoritative and how differences will be reconciled; avoid two conflicting final records.

1. Confirm that the agreed required information and real workflows are covered.
2. Resolve material mapping, access or record-history gaps before relying on the new method.
3. Train affected staff and deputies on entry, exceptions and fallback arrangements.
4. Record the cutover boundary and locations of retained historical evidence.
5. Check the first genuine records and address problems while the responsible people are available.
6. Schedule a proportionate follow-up review of retrieval, exceptions and staff use.

Common mistakes when moving food safety records

• Copying a software checklist without checking the applicable plan or programme.
• Retyping historical checks from memory to create a continuous dashboard.
• Confusing a submission timestamp, reminder or default value with the actual food check.
• Leaving completed paper records behind without an accessible archive index.
• Testing routine entry but never testing an exception, correction, export or unavailable service.
• Giving every user broad editing access, or leaving retrieval dependent on one employee.

Frequently asked questions

Can food safety records be kept electronically?

MPI’s SSS record guidance gives electronic options, and NP1 guidance also permits electronic recordkeeping. The content, availability and other requirements applying to the actual business still matter. Choose and test a method that preserves that evidence rather than relying on the format alone.

Do we have to import every paper record into the app?

Decide how retained evidence will remain identifiable, protected and retrievable under your requirements. An accessible archive may form part of the arrangement. Do not destroy records or abandon access just to complete a software move.

Does using an app change our food-safety limits or required checks?

Changing the recording medium does not by itself authorise those changes. Map the actual requirements first and assess any proposed change to the controls or plan separately. A provider’s standard field is not the source of the requirement.

Will the app guarantee a successful verification?

No. Records support the evidence of what the business actually does. A completed screen does not prove a task occurred correctly, that a problem was addressed or that the whole operation meets its requirements.

Can AFVA build or approve our software?

The support described here is food-safety process, document and evidence review. Agree that consulting scope with AFVA. The software provider is responsible for its technical functions; this article makes no claim that AFVA supplies software, performs migration engineering or grants regulatory app approval.

Prepare a focused record-workflow review

Bring your current plan or programme, the record types being moved, suitably redacted completed examples, proposed forms or screens, the provider’s demonstrated functions and a list of known gaps. Explain who enters and reviews the records, the devices used, how history will remain accessible and the intended switch date.

AFVA’s published consulting scope includes reviewing records and procedures, identifying practical gaps and improving food-safety systems. The business can use a focused review to clarify what its evidence needs to show before asking the provider to configure the technical solution. Consulting remains separate from registration, evaluation, independent verification and certification.

General information only: Requirements depend on the actual activities, plan or programme and applicable regulatory or customer arrangements. This guide is a recommended transition framework, not software approval, a technical security specification or permission to alter food-safety controls or discard records. Confirm the requirements applying to the business.