Ziel has spent nearly two decades targeting the thing that threatens every agricultural producer’s yield and reputation: microbial pathogens. Through patented Radio Frequency technology deployed across five continents, Ziel helps cannabis operators, food processors, and growers of nuts, seeds, dates, and prunes achieve safe, compliant product — without chemicals, without ionizing radiation, and without compromising organic certification.
But the compliance burden on Ziel’s customers doesn’t stop at the machine. The FDA regulates the records that surround that machine just as rigorously as the machine itself.
That’s where FDA 21 CFR Part 11 comes in — and where the Ziel Dashboard was built to help.
Title 21, Code of Federal Regulations, Part 11 governs the use of electronic records and electronic signatures in FDA-regulated industries. In plain terms: if your operation is subject to FDA oversight and you’re keeping records electronically — which every modern production operation is — those electronic records must meet specific requirements to be accepted as the legal equivalent of paper records and handwritten signatures.
For Ziel’s customers in food manufacturing, cannabis (in regulated state and international markets), and commercial agricultural processing, Part 11 isn’t optional. It’s the baseline for operating in a regulated environment.
The FDA defines five core criteria for Part 11 compliance. Here’s where the Ziel Dashboard stands on each.
The requirement: Documented evidence proving the system operates accurately and reliably for its intended use.
System validation under Part 11 means more than “the software works.” It means demonstrating — with documented test protocols — that the system consistently does what it’s supposed to do. This includes Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ), the industry-standard framework borrowed from pharmaceutical manufacturing.
The Ziel Dashboard is built on a professional development platform that provides platform-level validation documentation for the underlying infrastructure layer — the web server, security framework, and component model. This means the platform layer can be validated using manufacturer-supplied IQ/OQ/PQ documentation, giving the validation effort a documented, tested foundation to build on.
At IADN, we’ve built the application layer on top of that validated foundation, and the application’s core workflows — batch data capture, laboratory data ingestion, error trapping, and audit logging — have been designed with testability and documented reproducibility as explicit design goals. Validation documentation for the application layer is in active development.
Status: In progress — platform layer documentation available; application-level IQ/OQ/PQ protocols underway.
The requirement: Secure, computer-generated, time-stamped records that independently track the date and time of operator entries and actions, without altering previous data.
This is one of the most technically specific Part 11 requirements — and one where the Ziel Dashboard delivers in full.
Every data modification made anywhere in the system is captured automatically in a tamper-resistant audit log. Each entry records the user ID, the timestamp, the database table affected, and the specific field-level change — including the previous value and the new value. The audit trail is computer-generated, not user-populated. Users cannot edit or delete audit trail entries, including administrators. The data integrity of the log is enforced at the database layer.
The system also maintains two additional logs: a complete login history (every access attempt, successful or failed, with reason codes for failures) and a record of every user’s acknowledgment of the current Terms & Conditions at login. Together, these three logs give an auditor a complete, independently generated, time-stamped record of system access and data activity.
This audit architecture was built from day one at IADN using server-side scripting that executes exclusively on the web server. No audit record is created, modified, or deleted by client-side code — which means it cannot be manipulated through the browser by any user, at any privilege level.
Status: Fully met.
The requirement: Restricted system access limited only to authorized individuals using unique ID and password combinations.
The Ziel Dashboard’s access control model is multi-layered, built into the application at the framework level.
Every user account is tied to a unique email address. There are no shared credentials and no generic accounts. User accounts are provisioned exclusively through an invitation workflow — there is no self-registration path. An administrator creates the account, the system sends a registration email, and the user must set their own password and acknowledge the Terms & Conditions at first login before gaining any access. Registration status (INVITE, HOLD, ACTIVE) is controlled by the administrator at any time.
Password security exceeds the requirements of NIST SP 800-63B, which the FDA references as the technical baseline for password controls under Part 11 §300. Specifically:
Access within the system is controlled by configurable Security Groups. Individual controls, forms, and entire sections of the application can be restricted to specific roles, and the server renders only the elements a user is authorized to see — elements are absent from the page output entirely, not merely hidden.
Multi-factor authentication is available at the system, group, or individual user level, supporting email OTP, SMS OTP, and TOTP authenticator apps (achieving NIST AAL2 when the authenticator app method is used).
Session timeout is enforced at 15 minutes of inactivity, with a warning alert before expiration. The system also integrates with Pusher.com for real-time session management, giving Ziel’s operations team the ability to instantly terminate every active user session across the entire platform in the event of a security incident — a capability that exceeds the session management requirements of most compliance frameworks.
Status: Fully met.
The requirement: Built-in checks to enforce permitted sequencing of steps and ensure the validity of input data.
Ziel’s equipment — APEX 7, RFX, APEX 85, and SENTINEL units — transmits production data for every treatment cycle: batch identifiers, bag weight, cycle time, start and stop timestamps, equipment ID, strain, recipe, and temperature readings including maximum temperature and temperature spread. This data arrives as a CSV file generated by the Ewon monitoring unit at each site.
The Ziel Dashboard’s Python-based processing pipeline validates every data point in every CSV file before it is committed as a Batch Summary record. Values that fall outside expected ranges — unusual cycle times, temperature anomalies, batch identifiers that don’t match expected formats — are automatically flagged as errors rather than silently written to the production database.
These flagged records are surfaced to authorized administrators through the Error Trapping module, where each record can be reviewed, corrected if appropriate, and annotated with a documented reason for the correction. Every correction is automatically written to the audit trail. This workflow satisfies the Part 11 requirement that the system enforce the validity of input data and that any data corrections be traceable.
The same validation logic applies to laboratory data. Certificates of Analysis received from partner labs are parsed automatically, capturing approximately 184 individual data points per certificate. Out-of-scope values in any of those data points — Terpenes, Cannabinoids, Heavy Metals, Pesticides, Microbial content, and the other test categories — are flagged in a parallel PDF Data Error Trap module before they enter the Lab Data record.
Developed at IADN, this two-stream error trapping architecture — one for equipment CSV data and one for lab CoA data — gives Ziel and its customers demonstrable, auditable evidence that every production record was validated before it was accepted. That is precisely what Part 11 §11.10(f) requires.
Status: Fully met.
The requirement: E-signatures must be unique to one individual, strictly tied to their corresponding electronic record, and certified to the FDA.
This is the one criterion the Ziel Dashboard does not currently implement in its final form — but it is in active planning, and the implementation path is clearly defined.
A Part 11-compliant electronic signature is not a login. It’s a specific, formal act: a named individual signs a specific record at a specific time for a specific stated purpose — “Approved,” “Reviewed,” “Released to Market” — and that signature is permanently and unalterably bound to the record. The full name, timestamp, and meaning must be recorded, and organizations using electronic signatures for regulated records must certify their use to the FDA.
The Ziel Dashboard currently captures user acknowledgments at login (Terms & Conditions) and records every data action to the audit trail with user attribution. These are strong foundations for access accountability, but they do not yet meet the Part 11 electronic signature standard for batch or lab record approval.
Electronic signature capability is currently in the planning stage. The implementation approach will use third-party electronic signature platform integration via API. Several well-established providers offer FDA Part 11-compliant e-signature workflows that integrate with web applications through standard API connections, without requiring a custom-built signature infrastructure. This approach is both practical and proven: leading third-party e-signature services maintain their own Part 11 validation documentation and compliance certifications, which significantly reduces the implementation burden compared to engineering a bespoke signature system from scratch.
The foundation is already in place. The audit trail, user identity model, and role-based access controls already built into the Ziel Dashboard provide exactly what a compliant e-signature workflow requires — user identity is established, all record modifications are traceable, and the access control model supports per-record, per-action authorization. Adding a formal signature step is an integration task, not an architectural redesign.
Status: Planning stage — implementation via third-party e-signature API integration.
For Ziel’s customers operating within the European Union — or supplying EU-regulated markets — the relevant framework is EU GMP Annex 11: Computerised Systems (EudraLex Volume 4), published by the European Commission and overseen by the European Medicines Agency (EMA). Annex 11 governs computerised systems used in GMP-regulated manufacturing and sets requirements across the full system lifecycle: validation, data integrity, audit trails, access controls, change management, incident handling, business continuity, and electronic signatures.
EU GMP Annex 11 goes further than FDA Part 11 in one significant direction. Where Part 11 focuses tightly on the trustworthiness of the electronic record itself, Annex 11 also requires the organisation operating the system to maintain ongoing controls — formal change control, periodic system evaluation, documented incident management, and business continuity arrangements. For Ziel’s customers in EU-regulated food manufacturing and cannabis operations, this means the Ziel Dashboard needs to satisfy both the technical record-keeping requirements and a defined set of operational and governance requirements.
The Ziel Dashboard satisfies the core technical requirements of EU GMP Annex 11 already.
The core technical requirements of Annex 11 are already addressed by the application’s design. Annex 11 §9 (Audit Trails) requires computer-generated, time-stamped records of all GMP-relevant data changes and deletions, with reasons documented for any amendment. The Ziel Dashboard’s field-level audit log — capturing user, timestamp, previous value, and new value for every modification, with annotated reason for any error-trap correction — satisfies this in full. No user, including administrators, can amend or delete audit trail entries.
Annex 11 §12 (Security) requires physical and logical controls restricting system access to authorised persons. The multi-layer model — role-based Security Groups, invite-only provisioning, configurable MFA, session timeout with forced logout, and network-level filtering — satisfies this requirement. Annex 11 §6 (Accuracy Checks) requires that critical data entered into the system be checked for accuracy. The Error Trapping module — validating every data point in incoming CSV equipment files and parsed Certificate of Analysis records before committing them to the database — satisfies this directly. Annex 11 §5 (Data) requires built-in checks for the correct and secure processing of data exchanged between systems. Server-side processing and parameterised database queries address this at the architectural level.
EU GMP Annex 11 §14 requires that electronic signatures be unique to one individual, linked to their corresponding electronic record, and include the time and date the signature was applied. Under EU law, electronic signatures used in regulated contexts are governed by the eIDAS Regulation (EU) No 910/2014. For most GMP record-signing purposes — batch approval, quality review, record release — an Advanced Electronic Signature (AdES) under eIDAS is the appropriate level: uniquely linked to the signatory, capable of identifying the signatory, and created using data under the signatory’s sole control. Several established third-party e-signature providers offer eIDAS-compliant AdES workflows via API integration, making the planned implementation approach directly applicable to EU GMP requirements without a separate solution.
For EU operators, the compliance story mirrors the FDA Part 11 picture: the application’s data integrity, audit trail, and access control architecture is already built to the standard. The gap is in the operational and governance layer — a defined and achievable set of SOPs, review schedules, and validation documents that sit around the software rather than inside it.
FDA 21 CFR Part 11 was designed for an era when the shift from paper to electronic records was new and regulators needed a framework for trusting digital systems the way they trusted paper. Today, every serious production operation is electronic, and the question isn’t whether to comply — it’s how to build systems that make compliance straightforward rather than burdensome.
The Ziel Dashboard was designed from the beginning as a production-grade quality system, not a reporting bolt-on. The audit trails are automatic. The error trapping is built into the data pipeline. The access controls are layered from network edge to individual UI controls. The password security exceeds the regulatory baseline. Four of the five Part 11 criteria aren’t satisfied by workarounds — they’re satisfied by the design of the system itself. And that same foundation satisfies the core technical requirements of EU GMP Annex 11 without additional development.
The fifth criterion, electronic signatures, is in the planning stage and will be implemented through third-party e-signature API integration, addressing both FDA Part 11 and EU GMP Annex 11 requirements in a single solution.
For Ziel’s customers operating in regulated environments across food manufacturing, cannabis, and specialty agricultural processing — on either side of the Atlantic — this is what purpose-built compliance looks like.
The Ziel Dashboard was designed and developed by Steve Wood at IADN, LLC (iadn.com). Development platform by Alpha Software (Alpha Software).
To learn more about Ziel and their patented Radio Frequency remediation technology, visit ziel.com.
For information about FDA Part 11-compliant software development, contact IADN at iadn.com.
Steve Wood is an independent software consultant specializing in custom business applications, enterprise modernization, and systems integration. He develops secure, data-driven solutions using Alpha Anywhere, Python, JavaScript, Node.js, SQL Server, MariaDB, and related technologies, while also providing software architecture, project management, and long-term application support. His projects range from departmental business systems to enterprise applications that integrate databases, APIs, cloud services, and legacy platforms.
Steve's preferred development platform is Alpha Anywhere because it combines the speed of low-code development with the flexibility of traditional programming. Its integrated application server, database connectivity, mobile capabilities, and extensibility allow sophisticated web and business applications to be delivered in a fraction of the time required by many conventional development frameworks. By combining Alpha Anywhere with Python and modern web technologies, Steve helps organizations modernize existing systems while reducing development time, cost, and long-term maintenance.
Supporting modernization across Access, Alpha Anywhere, FileMaker, Clarion, FoxPro, and other long-standing platforms.
