HACCP Software Requirements

Skip key takeaways

Updated September 18, 2026

• The obligation is a running procedure, not a document EU law puts a permanent HACCP-based procedure on the food business operator, and the records are what prove it ran.
• A critical limit needs a version history Our storage rule is that a limit is never edited in place, because a past reading has to stay judgeable against the limit that applied to it.
• A monitoring record carries a person, a device and a limit version FDA guidance has the record dated and signed or initialed by whoever took the reading, so identity is a field rather than a session.
• Corrective action is a workflow, not a text box Cause, product disposition and a record of the action are the three elements FDA guidance names, and the plan says who is responsible before anything fails.
• Retention is a rule with a named party The Regulation leaves the period to implementing arrangements, so the platform stores rules rather than a default number.

Copy takeaways

HACCP software requirements start from something teams often meet late in a build: what a food business hands over is not a plan document, it is a stream of records proving the plan ran. EU law states the duty as a procedure that keeps running rather than a document that exists. Article 5(1) of Regulation (EC) No 852/2004 puts it on one named party in one sentence: "Food business operators shall put in place, implement and maintain a permanent procedure or procedures based on the HACCP principles." A form-first model is the failure we keep meeting: the fields match a printed template and nothing knows which limit applied when a reading was taken.

In short: four decisions carry most of the risk. Whether critical limits carry a version history, so a reading stays judgeable against the limit in force when somebody took it. A monitoring record that stores the observer, the device and the limit version rather than a value and a tick. Corrective action modeled as a workflow with states instead of a free-text box. And retention expressed as a rule with a named party, since none of the sources read for this article fixes a number. The entity table maps each of the seven principles onto the object it becomes.

The rules and the parties they name

Every obligation here belongs to somebody, and the party changes with the jurisdiction while the seven principles do not. In the European Union the duty-holder is the food business operator. Article 5(3) of the Regulation scopes it: "Paragraph 1 shall apply only to food business operators carrying out any stage of production, processing and distribution of food after primary production and those associated operations listed in Annex I."

The Regulation also declines to assume that every kitchen has a critical control point. Recital 15 of the base text says so: "In particular, it is necessary to recognise that, in certain food businesses, it is not possible to identify critical control points and that, in some cases, good hygienic practices can replace the monitoring of critical control points." A platform refusing to save a plan until somebody names a CCP cannot represent a business the law explicitly contemplates, and the workaround we see is a decorative CCP nobody needs to monitor.

The principles themselves are borrowed rather than invented. Recital 15 of the same Regulation names their origin and their intended elasticity: "The HACCP requirements should take account of the principles contained in the Codex Alimentarius. They should provide sufficient flexibility to be applicable in all situations, including in small businesses."

That Codex text is CXC 1-1969, General Principles of Food Hygiene, which the FAO and WHO Codex list of codes of practice carries under the Codex Committee on Food Hygiene with 2022 in its last-revision column and distributes as a PDF per language. This article cites it by title only.

In the United States the named party is a jurisdiction rather than an operator. The FDA Food Code is a model offered for adoption, which its landing page states plainly: "The Food Code is a model for safeguarding public health and ensuring food is unadulterated and honestly presented when offered to the consumer." A state, local, tribal or territorial authority adopts an edition, so the requirement a restaurant faces sits in the adopted code of its jurisdiction. That is a configuration boundary, which is why a US tenant needs a jurisdiction field before a retention setting.

The Food Standards Agency publishes its own guidance for UK operators in plain English and cites no instrument at all. Its overview of food safety management systems defines the object of the exercise: "A food safety management system is a written set of processes, checks, rules and records." Written, checked and recorded. Nothing in that definition is about software.

The same guidance separates two tiers. The page on creating a system puts the fuller tier above the toolkits: "An HACCP plan is a more detailed part of food safety management that focuses on identifying and controlling food safety risks." A small caterer working from a toolkit and a diary needs capture and retention. An operator running a formal plan needs the entity model below. The point of sale and the kitchen display are a separate build, covered in our restaurant software development guide.

Seven principles and seven entities

Article 5(2) of the Regulation enumerates the principles as law. The guidelines FDA publishes from the 1997 NACMCF document enumerate the same seven, naming them in one line on the HACCP principles page: "These principles include hazard analysis, CCP identification, establishing critical limits, monitoring procedures, corrective actions, verification procedures, and record-keeping and documentation."

Read that list as obligations and you get a form with seven sections. Read it as nouns and you get a schema.

The table is the short form of the whole article. Its principle column is sourced, from Article 5(2) and the FDA definitions quoted below. The entity and failure columns are Pharos Production practice and carry no citation. The field column is mixed: fields restating a sourced definition are sourced, the rest are ours.

Principle (sourced)	Entity in the data model (our practice)	Fields it carries (mixed)	Failure seen in practice (our practice)
Hazard analysis	Hazard and ProcessStep, joined many to many	Hazard type (biological, chemical or physical), process step, significance decision, rationale, control measure	Hazards kept as free text on the step, so the reason one was called significant is gone by the first review
Critical control points	CCP, a flagged process step with its own identity	CCP number, step reference, hazards controlled, owning role, decision answers	The CCP is a boolean on the step, so nobody can reconstruct when a step became one or stopped being one
Critical limits	CriticalLimit, versioned and never edited in place	Parameter, direction (minimum, maximum or both), value, unit, tolerance, effective from, source of the value	Limits edited in place, so a past reading can no longer be judged against the limit that applied to it
Monitoring	MonitoringRecord, append only	CCP, limit version, measured value, unit, timestamp, observer identity, device identity, method, pass or fail, note	The record stores a value but not the limit version or the device, so a calibration failure cannot be traced to the readings it spoiled
Corrective actions	CorrectiveAction, a workflow with states	Triggering record, cause, correction applied, product disposition, decided by, decided at, state, closure evidence	Corrective action kept as a text field on the failed reading, so disposition and cause can never be reported on
Verification	VerificationEvent and ValidationEvent, one scheduled and one triggered	Type, scope, scheduled for, performed at, performer, independence flag, records reviewed, outcome, resulting plan change	Verification recorded as a tick, with no link from the event to the records it actually reviewed
Documentation and records	Document and Record as two classes, each with its own retention rule	Class, owner, version, supersedes, effective from, retention rule, party the rule comes from, export state	One retention setting for the whole tenant, so a multi-jurisdiction operator cannot satisfy two rules at once
Prerequisite programs (not a principle)	PrerequisiteProgram, a separate graph referenced by hazards	Program type (cleaning, pest, maintenance, training, supplier, allergen), schedule, records produced, audit cadence	Prerequisite records mixed into the CCP stream, so the plan looks larger than it is and every review drowns

The last row is deliberately not a principle. The FDA guidelines keep prerequisite programs at arm's length from the plan: "Prerequisite programs are established and managed separately from the HACCP plan." Merge the two and, in our experience, the plan looks enormous while the first record review disappears under cleaning sheets that were never CCP monitoring.

Hazard analysis is a decision with a rationale

Points (a) and (b) of Article 5(2) put two entities in one sentence, and their relationship is the interesting part. The Regulation reads: "(a) identifying any hazards that must be prevented, eliminated or reduced to acceptable levels; (b) identifying the critical control points at the step or steps at which control is essential to prevent or eliminate a hazard or to reduce it to acceptable levels;". A hazard is not an attribute of a step. It is a link carrying a decision about whether that pairing is significant, which is why it needs a row of its own rather than a text area.

The reasoning behind it is part of the record set. Principle 7 of the FDA guidelines opens its list with it: "Generally, the records maintained for the HACCP System should include the following: A summary of the hazard analysis, including the rationale for determining hazards and control measures." Stored beside the decision, the rationale tells a later review why a hazard was dismissed.

Underneath the hazards sit the programs that make the analysis honest. The FSA guidance on creating a system names what the Safer Food, Better Business toolkits cover: "The SFBB toolkits include procedures for managing cross-contamination, cleaning, chilling and cooking." Pharos Production practice is to model those as a separate graph, one object per program type, each with its own schedule and record stream, referenced by the hazards it helps control. Cleaning, pest control, maintenance, training, supplier approval and allergen handling belong there. None is a CCP, and none is one of the seven principles in Article 5(2). The Regulation names cleaning, pest control, maintenance and training in its Annex II hygiene requirements, and the consolidated text adds allergen points, but it treats none of them as a HACCP principle.

Critical limits need a version history

Points (c) and (d) of Article 5(2) are the pair we find flattened into one column. The Regulation keeps them apart: "(c) establishing critical limits at critical control points which separate acceptability from unacceptability for the prevention, elimination or reduction of identified hazards; (d) establishing and implementing effective monitoring procedures at critical control points;". A limit separates acceptable from unacceptable. Monitoring tests a reading against it.

The field shape of a limit comes out of the FDA definition. The definitions section gives it as: "Critical Limit: A maximum and/or minimum value to which a biological, chemical or physical parameter must be controlled at a CCP to prevent, eliminate or reduce to an acceptable level the occurrence of a food safety hazard." A maximum or a minimum, so a limit needs a direction. A named biological, chemical or physical parameter, so it needs a parameter type. A value controlled at a CCP, so it needs a unit and a reference to the point it governs.

Our rule on top of that is a storage rule. A critical limit is never updated in place.

A change writes a new version with its own effective-from date and the old version stays readable, because a reading taken last March must stay judgeable against the limit in force last March. In our delivery experience teams that edit limits directly find the cost at the first inspection reaching back past a menu change.

What a monitoring record must carry

Monitoring is the one principle whose definition already contains its output. The FDA guidelines define it as: "Monitor: To conduct a planned sequence of observations or measurements to assess whether a CCP is under control and to produce an accurate record for future use in verification." The record is in the definition rather than a by-product, and the definition names its consumer: verification, later, by somebody else. That is the argument for an append-only table rather than a checklist's current state.

Attribution is stated just as plainly. The same guidance says who signs: "All records and documents associated with CCP monitoring should be dated and signed or initialed by the person doing the monitoring." A shared tablet logged in as one account does not meet that. The identity on the record is the person who took the reading, so session identity and record attribution are separate concerns.

From those two sentences plus delivery experience, Pharos Production keeps ten fields: the CCP, the limit version in force, the measured value, its unit, the observation timestamp, the observer identity, the device identity, the method, the pass or fail decision computed at write time and a note. The decision is stored rather than derived on read, because deriving it later runs today's limit against yesterday's reading.

Frequency is a field too, and continuity is the ideal rather than the rule. The monitoring section states the preference: "Ideally, monitoring should be continuous, which is possible with many types of physical and chemical methods." The fallback follows: "When it is not possible to monitor a CCP on a continuous basis, it is necessary to establish a monitoring frequency and procedure that will be reliable enough to indicate that the CCP is under control." So a CCP carries either a continuous source or a frequency and a procedure, and the plan says which.

Probes and sensors are how continuity is usually bought, and they change the record without removing it. A fixed probe writes the row an operator would have written, plus the device identity, its firmware version, its calibration state and a flag marking the reading unattended. Our IoT development guide covers the ingestion side. A probe with no calibration link makes every reading it wrote unjudgeable, which is the unversioned-limit failure seen from the other end.

Offline capture is our practice, not a requirement in any text read for this article, and it splits the timestamp into three fields: the observation time on the device, the time the server received the row and the device clock offset, so a reading taken at 11:05 and synced at 19:00 still lands in the right shift. Sync is idempotent, so a retried upload cannot create a second record.

Corrective action as a workflow with states

Point (e) of Article 5(2) names the trigger, and the trigger is internal. The Regulation reads: "(e) establishing corrective actions when monitoring indicates that a critical control point is not under control;"

Monitoring indicates. Not an inspector, not a complaint, not an audit finding. The system detecting the deviation opens the action, so it belongs in the same database as the reading that caused it.

Its internal structure is specified rather than left open. The FDA guidelines list three elements: "Therefore, corrective actions should include the following elements: (a) determine and correct the cause of non-compliance; (b) determine the disposition of non-compliant product and (c) record the corrective actions that have been taken." Cause and disposition are separate decisions, often made by different people at different times, and the third element records the action itself.

The plan also pre-declares the workflow before anything triggers it. The same page sets the minimum: "As a minimum, the HACCP plan should specify what is done when a deviation occurs, who is responsible for implementing the corrective actions, and that a record will be developed and maintained of the actions taken." What is done, who is responsible and that a record will exist. A state machine with an owner, declared per CCP at plan time.

We model it as four states. Open on the failing reading. Cause determined, categorized rather than typed. Disposition decided, naming what happened to the product and who decided. Closed, with evidence and the closing identity.

Verification and review as scheduled events

Point (f) of Article 5(2) fixes a cadence without fixing an interval, and the closing sentence of the paragraph adds a second trigger. The Regulation puts verification on a regular footing: "(f) establishing procedures, which shall be carried out regularly, to verify that the measures outlined in subparagraphs (a) to (e) are working effectively;" and lets a change reopen the procedure: "When any modification is made in the product, process, or any step, food business operators shall review the procedure and make the necessary changes to it." A menu change, a new supplier, a new oven. Each is an event in the data model pointing at the plan version it produced.

Verification is defined by exclusion. The FDA guidelines put it as: "Verification is defined as those activities, other than monitoring, that determine the validity of the HACCP plan and that the system is operating according to the plan." Its everyday form is a review of monitoring and corrective action records rather than end-product testing, and that link is what a tick-box implementation never stores. The event carries the set of records it reviewed.

Validation sits beside it as a differently triggered event. The same guidance lists its triggers: "For example, validations are conducted when there is an unexplained system failure; a significant product, process or packaging change occurs; or new hazards are recognized." One more event carries an independence requirement: "In addition, a periodic comprehensive verification of the HACCP system should be conducted by an unbiased, independent authority." Hence a performer and an independence flag on the entity rather than an assumption that the reviewer is staff.

Calibration decides where maintenance data lives. The guidelines allow it into the plan: "During the development of a HACCP plan, the HACCP team may decide that the routine maintenance and calibration of an oven should be included in the plan as an activity of verification." Our practice adds one thing: a calibration event stores the device and the period it covers, so a failure resolves to the exact readings taken since the last good one.

The audit trail and the role model behind it

Point (g) of Article 5(2) sizes everything else, and it contains its own proportionality rule. The Regulation reads: "(g) establishing documents and records commensurate with the nature and size of the food business to demonstrate the effective application of the measures outlined in subparagraphs (a) to (f)."

A five-seat cafe and a central production unit answer to the same principles and not to the same weight of documentation, so record depth is a tenant-level setting rather than a constant.

The FSA states the record duty as an action list, and one item repays reading closely. The overview page tells a business to "keep records of your food safety systems, checks and how you’ve put things right". Corrective actions are named as part of the record set rather than as an exception, which is the sentence to cite when somebody proposes keeping deviations in a separate incident tool.

Immutability is our engineering position and not a requirement in any text read for this article. Monitoring rows and corrective actions are written once. A correction is a new row superseding an earlier one, with its own author, timestamp and reason, and the superseded row stays readable. Every write records who made it and when, in site-local time as well as UTC, because an inspection question is about a shift.

None of the pages read for this article describes multi-site operation or role-based access, so what follows is Pharos Production practice alone. Roles map to verbs rather than job titles: record, review, approve a plan change, close a corrective action, administer retention. A site owns its records, a plan is versioned per site even when it starts as a brand template and a group role reads across sites without gaining the right to record on one. Retrofitting that split costs a migration on the largest table in the system.

A central production unit is modeled twice in the same practice. It is a site with its own plan and its own limits, and a supplier to the sites it feeds, which record what arrived and against which delivery. Referencing those records rather than copying them keeps one source of truth and still shows an inspector the chain.

Retention as a rule rather than a number

The Regulation splits documents from records and treats them differently. Article 5(4) of the base text states both duties: "(b) ensure that any documents describing the procedures developed in accordance with this Article are up-to-date at all times; (c) retain any other documents and records for an appropriate period." Procedures must be current at all times, which is version control. Other records are kept for an appropriate period, which is no number at all.

It stays not a number on purpose. Article 5(5) of the same Regulation hands the period to implementing arrangements: "Such arrangements may also specify the period during which food business operators shall retain documents and records in accordance with paragraph 4(c)." So an EU tenant's retention setting is a rule with a named party attached, and the party is not the Regulation.

Where an operational answer exists it is a trigger, not a duration. The FSA Safer Food, Better Business pack, which applies to England and Wales, tells a small caterer: "Store all your completed diary pages safely until your next visit from a local authority food safety officer." Until the next visit. A date nobody can compute in advance, which a retention engine has to accept as input.

So the engine ships with no default number. Every record class carries a rule, the rule names the party it came from, an effective-from date and a basis that may be a duration, an event or a trigger such as an inspection visit. Legal holds override everything and are themselves recorded. In our experience this replaces one retention field per tenant, which breaks the first time an operator runs sites under two jurisdictions and cannot be repaired once deletion has run.

What the inspector asks for

The reason all of this is kept is one FSA sentence. The overview page says: "If your business is involved in a food safety incident, you will need to show your records as evidence of how you keep food safe."

Show your records as evidence. Not summarize them, not attest to them. The export path is a first-class feature rather than a reporting nicety.

None of the pages read for this article names a file format or an export standard, so nobody should build one as though a receiving system were waiting. What an inspection asks for is narrower: every record for one site over one date range, each reading beside the limit version in force at the time, each deviation beside its corrective action and its closure. Our practice is to generate that as a paginated document a person can read, with the rows behind it available as a file. The one constraint is reproducibility: the same range regenerated next year returns the same content, which holds only if the tables underneath are append-only.

How Pharos Production helps

A HACCP platform is five pieces of software and one habit: the plan model with its versioned limits, a capture path that works offline on a kitchen device, the corrective action workflow with real states, the verification and calibration events linking back to the records they cover and the retention and export engine that answers an inspector. The habit is that nothing is edited in place.

Our food and restaurant software development practice builds that layer: the entity model above, the probe ingestion described here writing the same record an operator would and an export a food safety officer can read without a login. We do not sell a HACCP plan and we do not write one. We build the system that keeps the plan running and proves that it did.

Sources: Regulation (EC) No 852/2004 on the hygiene of foodstuffs, base Official Journal text via the EU Publications Office; FDA HACCP Principles and Application Guidelines, the NACMCF document adopted 14 August 1997; the FDA Food Code 2022 landing page; the FAO and WHO Codex list of codes of practice for CXC 1-1969, General Principles of Food Hygiene; Food Standards Agency guidance on GOV.UK, including Safer Food, Better Business. Read on 17 September 2026. Engineering guidance, not legal advice.

FAQ

Last updated: September 18, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. Should a HACCP module be built or bought?

  Copy link Copies a direct link to this answer to your clipboard.

  Buy when the operation fits a packaged model and the records can leave intact: one jurisdiction, a menu that changes slowly and no need to join food safety records to anything else you run. Build when the plan has to live inside an existing operations platform, when two jurisdictions impose different retention rules or when probes and kitchen devices already feed another system.

  The deciding question is rarely the feature list. It is whether you can export every record with its limit version and its attribution on the day you leave the vendor.

• When is a prerequisite program enough on its own?

  Copy link Copies a direct link to this answer to your clipboard.

  When the hazard analysis finds no step where control is essential, which is a conclusion the analysis is allowed to reach rather than a shortcut around it. Cleaning, supplier approval, staff training and temperature-controlled storage can carry a hazard that never becomes a CCP.

  What the platform has to store in that case is the reasoning: the step considered, the hazard, the control measure relied on and the decision that no limit is set. A plan with no CCP and no recorded reasoning looks identical to a plan nobody finished.

• What changes when a caterer outgrows an SFBB toolkit?

  Copy link Copies a direct link to this answer to your clipboard.

  The diary becomes a plan, and the platform has to carry both at once during the transition. A toolkit user records checks against printed procedures, with no measured limits and no CCP numbering, so the first step is to keep capturing those checks unchanged while the hazard analysis runs beside them.

  Our practice is to let one site hold toolkit records and plan records in the same store, each record class naming the regime it came from. The old diary pages stay evidence long after the plan supersedes the toolkit.

• What happens when one record class falls under two jurisdictions?

  Copy link Copies a direct link to this answer to your clipboard.

  Hold both rules rather than resolving them at write time. Our practice is to attach every applicable retention rule to the record class, each rule naming the party it came from and its effective-from date.

  The longest surviving rule governs deletion, and legal holds sit above all of them. A single reconciled number loses the reason a record was kept, so a later audit cannot tell which regime demanded it. The same shape answers a site that changes jurisdiction, because the rules in force when a record was written travel with the record.

• Who owns the plan in a franchise?

  Copy link Copies a direct link to this answer to your clipboard.

  Split ownership from authorship in the schema before the first franchise agreement raises the question. A brand can author a template plan with its hazards, steps and suggested limits, while the records belong to the operator of the site that produced them.

  Model a site plan as a version derived from a template version, with the divergences visible, so a brand can see which sites have drifted while a franchisee can still tighten a limit for a local supplier. Without that link a brand-wide update silently overwrites local decisions.

• How many critical control points should a plan have?

  Copy link Copies a direct link to this answer to your clipboard.

  No number answers this, and a product that suggests one is guessing on behalf of a business it has never seen. The count falls out of the process steps and the hazard analysis: a cook-serve kitchen and a cook-chill unit with a blast chiller reach different answers from the same menu.

  What a platform can do is make the count visible and make growth suspicious, because a plan acquiring control points every quarter has, in the cases we have seen, prerequisite program controls miscategorized, which multiplies monitoring work without improving safety.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.