Custom software for IFS and BRCGS certification
With IFS there are ten requirements, one of which is enough to have the certificate refused. And for a few years now, at least every third certification audit must be unannounced, so there is no longer a week in which you can put everything right in advance. Together, those two change the challenge: not becoming audit-ready, but staying audit-ready.
Why the challenge has shifted
IFS Food has been updated to version 8, incorporating Codex Alimentarius, the requirements of ISO 22003-2 and the GFSI benchmark. BRCGS's current standard is Issue 9, and the consultation for the next version has already taken place. The two standards have therefore moved closer together, but their assessment methodologies still differ.
The sharpest element of IFS is the knock-out requirements. These are ten specific requirements, where failing even one means the certificate is refused. Not downgraded, not scored lower: refused. Someone with their paperwork in order but a gap on one of those ten points fares worse than someone who scores a six across the board.
Then there is the unannounced element. Since 1 January 2021, at least every third certification audit under IFS Food must take place unannounced. The week you used to tidy up in no longer exists. What is in place on an ordinary Tuesday is what the auditor sees.
BRCGS focuses on a different point: the traceability test, which must run forwards and backwards, including mass balance, within four hours. For how to record your data so that this works, see BRCGS software for traceability and mass balance.
How we build this
The requirement and its evidence are one and the same here. If the evidence is created naturally as the work is done, an unannounced audit is just an ordinary day.
Ten requirements receive their own treatment and their own view. Right now they are buried among hundreds of other requirements, yet they are the only ones that can cost you the certificate.
Temperature records, inspection rounds, training certificates and supplier declarations flow in from the systems where they are already recorded, rather than from a collection exercise beforehand.
Supplier certificates, training courses, calibrations and inspections all have expiry dates. They lapse quietly, and on an unannounced day that is exactly the gap that gets found.
We pick a random date in the past and check whether the evidence for that day exists. Whatever is missing then will be missing later too.
What the software actually does
The register of requirements and their evidence underpins everything. Which components you need depends on which standard you operate under and how much you already record.
Knock-out requirements monitored separately
The ten requirements that could cost you the certificate get their own view with their current status. A gap there is a different kind of problem from a gap elsewhere, and that distinction belongs in the system.
Validity monitored rather than checked
Calibrations, training, inspections and supplier declarations expire. The system warns you in advance, because on an unannounced day finding out afterwards is the same as not knowing.
Evidence from daily recording
Measurements, rounds and checks come in through integrations with the systems your people already work in. Evidence that a collection round requires is missing on exactly the wrong day.
Non-conformities with root cause analysis and follow-up
A recorded non-conformity with a demonstrable correction carries different weight than one that was never followed up. In an audit, the latter is more damaging than the non-conformity itself.
Two standards side by side
If you operate both IFS and BRCGS, the evidence overlaps but the methodology differs. A single evidence register with two reporting views means you avoid keeping everything twice.
A file on any given date
Not the current position but the position on the day the auditor chooses. That is the question asked in an unannounced audit, and it is one most systems cannot answer.
Who we build for
Where evidence originates varies greatly from company to company. Four situations.
Production and processing
Most of the evidence is created on the shop floor: measurements, rounds, cleaning. The challenge is not recording it but linking it to the requirement, so that an auditor can follow the trail.
Storage and distribution
For IFS Logistics, the focus is on temperature, segregation and handling. The number of touchpoints is high and the evidence is per shipment, which places different demands on the records.
Private label for retail
Your buyer sets requirements on top of the standard and may also visit you in person. That means you are tracking two frameworks, and it pays to support both from a single evidence register.
Businesses with multiple sites
A certificate applies per site, and a gap in one place does not automatically affect the whole. What you want to know is whether the same shortcoming exists elsewhere before the auditor arrives. Day-to-day checks on the floor run through the IFS app.
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
Standards are revised periodically and requirements shift as a result. Everything relating to the requirements list and the assessment methodology should be configurable and kept per version.
Why Appfront
One knockout requirement is enough to lose the certificate
We treat those ten separately, with their own view and their own monitoring. Among hundreds of other requirements they do not stand out, and that is precisely the risk.
Unannounced means every day counts
There is no longer a week to tidy up in. That is why we build monitoring in advance, rather than a checklist you work through before the audit.
Evidence that gathers itself
We retrieve what your people already record via integrations. A second registration yields no more evidence, only more work.
The question concerns a date, not today
We build the reconstruction of the file as at any given day, because that is what an auditor asks for.
Security and privacy
A certification file contains commercially sensitive information: your recipes touch on allergen records, your supplier declarations reveal your purchasing, and your non-conformity list shows where things went wrong. We set access by role, show a supplier in the portal only their own declarations, and log every instance of access.
On the evidence side, one requirement carries more weight here than elsewhere. A register that can be updated after the fact is not evidence; indeed, an auditor who finds that measurements were amended retrospectively has found a bigger problem than the measurement itself. We therefore record measurements and checks immutably, with time and person, and treat any correction as a visible correction alongside the original value. How we handle security ourselves is set out in our information security policy; reports from outside come through our CVD policy.
Frequently asked questions about IFS and BRCGS
KO stands for knockout. It refers to a limited number of specific requirements in the IFS standard where failing a single one means the certificate is refused. This is a different mechanism from the ordinary scoring, where shortcomings lead to a lower outcome. Which requirements these are is set out in the current version of the standard.
For IFS Food, at least every third certification audit must be unannounced; this requirement has applied since the start of 2021. In practice, it means you do not know in which year the audit will fall, so you must be audit-ready every year. BRCGS also has an unannounced variant; how that plays out for you depends on your certification body.
An audit file with non-conformity management concerns gathering evidence and following up findings. This page addresses the two mechanisms that can cost you the certificate: the KO requirements and the unannounced audit. In practice, you build both on a single register.
Yes, and that is usually the reason for building something in the first place. The evidence largely overlaps; the systematics and the assessment differ. We therefore maintain one evidence register with a separate read-out per standard, rather than two files that drift apart.
Requirements shift and sometimes the numbering changes. That is why we keep the requirements list as a setting and record against which version each piece of evidence was captured. Without that, you cannot account for an audit covering an earlier period against the requirements that applied then.
Mainly by shifting the question from searching to showing. An auditor picks a date and a batch and asks for the evidence. If it sits in one overview, that conversation is short. Otherwise a search through folders begins while someone watches, and that in itself is a signal.
No. Monitoring of critical control points is a separate process with its own frequencies and its own limits. It does produce evidence that ends up in the certification file; we connect the two rather than blending them.
That depends on the number of sites, which standards you operate and how much evidence can be retrieved automatically. The requirements register with knock-out monitoring and validity tracking is typically quick to put to use and removes the greatest risk; the integrations cost more. We give a reasoned estimate following the discovery phase.
Audit-ready every day?
Pick a random Tuesday from last quarter and try to produce the evidence for that day's knock-out requirements. How long that takes is what an unannounced audit measures. We build this as a standalone application and as part of a broader custom software project.