IFS Food v8 BRCGS Issue 9 Unannounced audits possible

Building an IFS Food and BRCGS audit file

IFS Food and BRCGS are not a legal requirement but a retail condition, and without certification your products will not make it onto the shelf. Now that audits can be unannounced, preparing in the weeks beforehand is no longer an option. Appfront builds a file that is continuously up to date, where deviations lead to a completed corrective action.

What IFS and BRCGS require from your records

Both standards are recognised within the Global Food Safety Initiative and are required by retailers as a condition of supply. Since January 2024, IFS Food version 8 has been mandatory, with knock-out criteria that feed directly into the outcome if not met, and a B-grade score that counts as a non-conformity. Since Issue 9, BRCGS Food Safety has included twelve fundamental requirements, including HACCP, internal audits, supplier management, corrective and preventive actions, traceability and allergen management.

The fundamental change over recent years is that audits can take place without notice. Since 2020, GFSI has required every site to be audited unannounced at least once every three years, and IFS makes this visible on the certificate. As a result, the practice of a team updating its records in the weeks before an audit no longer works. The file has to be accurate every day.

In practice, things tend to go wrong with non-conformities. An audit produces findings that must be corrected within a set deadline, with evidence, and the deadline varies by category and by scheme. The same route applies to internal audits, complaints and production deviations. If those four live in different systems or in a shared folder, you cannot demonstrate at the next audit that a problem has been structurally resolved rather than merely fixed once.

This file rarely stands alone. Records on the shop floor often run through the same app as your inspections, and equipment subject to statutory inspection in production belongs in an inspection log that contributes to the same evidence. Wherever possible, we build these elements as one integrated whole, so that a check does not need to be recorded in two places.

This page is about the file itself: deviations, corrections and the chain of evidence around them. If you are looking for the level above that, how to keep track of the KO requirements separately and how to handle an unannounced audit, see IFS and BRCGS software.

How we build your audit file

We start with the requirements of your standard and work back to what needs to be recorded every day. That way the file answers the auditor's question, rather than being an archive that only looks like one.

1
Defining the standard and scope

Whether you work under IFS, BRCGS or both, and which version. We go through the requirements and decide, for each one, what evidence you need to be able to show and where it comes from. If you are working to two standards, we look primarily for the overlap, because duplicate record-keeping is the biggest waste in this area.

2
Designing the deviation routes

Findings from an audit, from an internal audit, from complaints and from production all follow the same route: register, determine the cause, correct, verify and close. One route, several entry points. That is the core of the system and where most of the design decisions lie.

3
Building in sprints

We work in sprints and start with deviation management, because that is where most of the day-to-day activity happens. Your quality department takes part and checks each sprint against real findings from your most recent audit.

4
Mock audit and handover

Before handover, we go through the file with an auditor's questions in mind: show that this requirement is being met, and show what happened with this finding. Anything that cannot be shown in two clicks, we adjust.

What the software actually does

Six components that together make up the file. Which ones you need depends on your standard and on how many sites and product groups you have.

One route for all deviations

Audit findings, internal audits, complaints and production deviations follow the same steps: registration, root cause analysis, correction, verification and closure. A deviation is only closed once someone has confirmed that the measure works, not when someone has written it down.

Deadlines that vary by class

The remediation deadline depends on the class of the finding and on the standard; a serious finding has a considerably shorter deadline than a minor one. The system calculates per finding and alerts the person responsible, with escalation as the date approaches.

Requirements with their evidence

For each requirement in your standard, the document, record or measurement that demonstrates compliance is documented, along with whether that evidence is still current. This is the table an auditor works through, and the place where loose references go out of date fastest.

Production records

Temperatures, metal detection checks, hygiene rounds and glass breakage checks are entered where they arise, with time and operator. An out-of-range value automatically starts the deviation route rather than simply sitting in a logbook.

Supplier evaluation

Both standards require demonstrable management of your suppliers: certificates, specifications and assessments, with validity dates. A portal in which your supplier uploads documents directly keeps this current without your staff having to chase it.

Audit mode for the day itself

A view organised according to the requirements of your standard, so that during the audit you go straight to the evidence requested. In an unannounced audit, that is the difference between carrying on calmly and searching while someone watches over your shoulder.

Who we build for

Four situations in which this file most quickly gets out of hand. Usually the trigger is an audit that went less well than expected.

Food producers

The core of both schemes. Production records and the quality file overlap here, and an integration with your production system is often part of the same solution.

Packers and co-packers

You produce for third-party brands, each of which brings its own requirements and audits. On top of IFS or BRCGS you then have customer-specific requirements, and these need to fit in the same file without becoming a second set of records.

Storage and distribution

Other scheme variants, but the same approach: traceability, temperature monitoring and deviations that lead to a corrective action. Often across several sites, so the question is how you keep central oversight.

Companies with multiple certificates

IFS, BRCGS, an organic certification and sometimes ISO alongside. The gain lies in recording evidence once, where it serves multiple requirements, rather than maintaining four separate files. If a quality management system is already in place, we build on it.

Not yet sure about a large project?

Test your idea first: a working prototype in 1 day

With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.

Explore OneDayBuild →

Technology and integrations

What we deploy depends on your situation. For records made on the shop floor, usability weighs most: a screen that asks too much gets filled in from memory at the end of the shift, and then the record is worthless as evidence.

For FSSC 22000, with evidence per requirement and always ready for an unannounced audit, there is our software for the FSSC 22000 audit file.

If you hold AEO status and need to keep track of control measures, there is our page on an AEO control measures file.

Node.js / Python / .NET PostgreSQL Native iOS and Android Offline registration on the shop floor QR labels at control points Document management with versions and approval Integration with production system Integration with complaints handling Import from measuring equipment Supplier portal Alerts and escalation on deadlines Audit mode per scheme Full audit logging EU hosting

Why Appfront

Built around the audit

We design from what an auditor asks and test that with a pilot run before handover. That is more concrete than meeting a standard on paper.

Closing requires verification

A deviation that closes because someone clicks a button is exactly what returns at the next audit. We build the verification step as a separate action performed by another person.

Continuously up to date

Unannounced audits make it impossible to catch up in advance. We set it up so that evidence is created where the work happens, because that is the only way to be right every day.

One piece of evidence, several requirements

If you work under two schemes, the requirements overlap considerably. We link evidence to several requirements at once, so you don't have to keep two records of the same reality.

Security and privacy

An audit file contains little personal data, but it does record who carried out which check and who was responsible for a deviation. That can be traced back to an employee, which is sensitive, because a deviation can look like a personal failing when it is usually a process problem. We therefore focus reporting on the process rather than the individual employee, and limit access to who did what to those who need it.

From a business perspective, what weighs more is that this file contains your recipes, specifications and customer agreements, and with co-packers also those of your clients. Access is therefore granted by role and by product group, with a separate temporary role for auditors who see only what falls within their scope. Records that serve as evidence cannot be changed silently: a correction is visible as a correction and does not overwrite the original. How we handle security ourselves is set out in our information security policy; reports from outside go through our vulnerability disclosure policy.

If your raw material comes from your own cultivation or from fixed growers, a separate certificate applies. For the cultivation side we work this out with GlobalG.A.P. farm records and audit.

Frequently asked questions about the audit file

Both are GFSI-recognised and cover much the same ground, but they differ in structure and assessment. IFS works with a points score per requirement and with knock-out requirements that feed directly into the outcome; since version 8, the B-score counts as a deviation again. BRCGS works with fundamental requirements and a classification of non-conformities. Which one you need is determined by your customer; some producers hold both because different retailers ask for different schemes.

Since 2020, GFSI has required that every site be audited unannounced at least once every three years; with IFS, this is visible on the certificate. In practice, the approach where a team updates the file in the weeks before the audit no longer works. That is precisely why organisations are building software for this: the evidence has to be created where the work happens, not compiled afterwards.

This varies by scheme and by the class of finding: the more serious, the shorter the deadline. For the most severe categories it is a matter of weeks, for lighter ones it is longer. Because the exact deadlines can differ by scheme and by version, we make them configurable rather than hard-coding them. What we do enforce is that the clock starts running the moment the issue is identified.

No. Your HACCP plan remains the document in which you record your hazards, critical control points and control measures; that is substantive work for your quality team. The software carries it out: it turns the control measures into records with a frequency, monitors whether they have been carried out, and starts the deviation route when a limit is exceeded. If your process changes, you revise the plan and we then adjust the software accordingly.

No, and that's usually the reason to act. The requirements overlap considerably, so we link each piece of evidence to every requirement it meets instead of duplicating it. In audit mode, the auditor sees the file organised according to their own scheme. In practice, that saves more work than any other feature.

To some extent, yes. Temperature loggers, metal detectors and weighing equipment often produce structured data, which can go straight into the file so that nobody has to type it in. Hygiene rounds and visual checks remain manual, but with a scan at the control point so that the record is tied to the right location and the right time. What is possible depends on your equipment; we establish that during the discovery phase.

Both schemes require demonstrable supplier management: valid certificates, up-to-date specifications and periodic assessment. In practice, that means chasing documents that have expired. A portal in which your supplier uploads their own documents, and in which you can see what is missing or about to expire, takes that work away from your quality department and keeps the file up to date.

That depends on the number of locations, the number of schemes and how many production records need to be connected. Deviation management is usually the quickest to put to use and delivers the most value, while integrations with measuring equipment take the most work. We give a reasoned estimate after the discovery phase, once we know which records are created where.

Ready to build an audit file?

Tell us which scheme you fall under and where the last audit got stuck, and we will help you think through the deviation route, the records on the shop floor and the overlap between your schemes. We build this as a standalone application and as part of a broader custom software development or web application project.

Edit content