The bottom line: Compliance features that are bolted onto a manufacturing platform after the fact are typically incomplete and difficult to maintain. ProAlert's audit trail, login logging, and threshold governance are built into the same SQL Server (Structured Query Language Server) schema that runs OEE (Overall Equipment Effectiveness), maintenance, and production... which means every quality-relevant action is recorded in context, with full before/after values, without a separate compliance layer to configure or maintain.

What Auditors Actually Ask For

A 21 CFR Part 11 audit for a manufacturing software system typically focuses on five areas. ProAlert addresses all five natively, without a compliance add-on package.

Audit Focus Area	What the Auditor Asks	ProAlert Evidence
Electronic Records Integrity	Can you prove this record hasn't been altered since it was created?	Every change is captured with the user, the timestamp, the entity and field modified, and the before and after values. Original creation records are never overwritten. Retrieval is currently by query against the audit tables... a built-in reviewer view is in development.
Electronic Signatures	Who authorized this action and when?	PIN-verified call closures and work order sign-offs create a signature record tied to a real user identity, not a shared credential. GPS timestamp at each lifecycle step.
Access Control and Login Auditing	Who had access to this system and when did they log in?	Login audit log records every successful login, logout, and failed attempt with timestamp, user ID, and IP address. Password policy enforcement is configurable with complexity, expiration, and history rules.
Scrap and Quality Record Traceability	Show me every scrap event for this product over the last 90 days with operator attribution.	Every scrap record includes product, asset, die cavity, operator, quantity, timestamp, and disposition. Threshold violations include supervisor approval record with corrective action notes.
System Validation Documentation	What validation category does this system fall under?	ProAlert is classified as GAMP (Good Automated Manufacturing Practice) 5 Category 4 (Configured Product). Validation documentation is available to customers as part of the implementation package.

ProAlert nonconformance report register listing seven NCRs with three open and four requiring corrective action, each row carrying its severity, its CAPA state and the inspection, audit or scrap record it came from — **The register an auditor asks to see.** Seven nonconformances, each numbered, graded and dated, four of them already escalated to corrective action. What matters is the left-hand column: these were not typed up after the fact. They were raised by the system from a scrap event, a failed pre-shift check, an audit finding and a downtime call, so the record and the thing it describes are the same record.

ProAlert inspection template library listing twelve active templates by code, name, frequency and number of checkpoints, covering calibration verification, first article inspection, preventive maintenance completion and pre-shift safety checks — **And the procedures those findings were raised against.** Twelve active templates, each with a code, a stated frequency and a fixed number of checkpoints: calibration verification, first article inspection, preventive maintenance completion, pre-shift safety checks. The failed pre-shift check in the register above is a failed checkpoint on one of these, not a note someone typed afterwards. The count of checkpoints is part of the template rather than left to the inspector, which is what makes two runs of the same procedure comparable.

ProAlert mobile inspection in progress on a technician's phone, step four of six of a preventive maintenance completion check, showing the critical and required checkpoint Safety Devices Re-Enabled with its instruction to confirm all guards, covers and interlocks removed during the PM have been reinstalled and tested, the pass criteria and the fail criteria beneath it, and large Pass, Fail and N/A buttons with an Add Notes action and Previous and Next navigation — **And one of those procedures being run, at the machine.** Step four of six of the preventive maintenance completion check from the library above, stopped on a checkpoint the template marks critical and required. The instruction, the pass criteria and the fail criteria are all on the glass, so what counts as a pass is the template's definition rather than the inspector's memory of it, and Pass, Fail and N/A are the only three answers the record will take. The checkpoint on screen asks whether every guard, cover and interlock removed during the work has been put back and tested, which is the kind of finding that becomes a nonconformance in the register at the top of this section rather than a note nobody reads.

ProAlert failure analysis dashboard over a year, ISO 14224 compliant, showing 66 failures with nine open and five critical, 117.3 hours of downtime, a mean time to repair of 1.85 hours, 26,188 dollars of repair cost, a Pareto of failures by category, a donut of the top failure modes, a root cause distribution and a monthly trend, above a list of the most recent open failures — **And the failure record underneath both of them.** A year of equipment failures classified to ISO 14224: 66 events, 117.3 hours of downtime, a mean time to repair of 1.85 hours and $26,188 of repair cost, sorted into a category Pareto, a top failure mode donut and a root cause distribution. Nine are still open and five are critical, and the screen says so rather than reporting a closed book. This is the evidence layer an auditor works down into when a nonconformance names an equipment failure, and the monthly trend is the thing the analysis was for.

ProAlert failure record register over a six month window, headed ISO 14224 Compliant Failure Event Log, listing 66 records of which 18 are visible, each with its own record number, the asset it happened on, what failed, the failure category and the specific failure mode such as bearing failure, lubrication failure or network comm fault, the date and time it was detected, the hours of downtime, a status of open, in analysis or completed, and whether root cause analysis is finished, with filters for date range, asset, status and category above the table and CSV and Excel export buttons in the header — **The same 66 events, one row at a time.** The chart above is the argument; this is what it is made of. Every failure carries its own number, which is what a finding cites, and its own failure mode rather than just the category: the dashboard counts a category, and this says which records made up that count and whether they were bearings, belts, couplings, seals, lubrication or fasteners. Filter it by asset, status, category or date and the two buttons top right export exactly what you filtered, as CSV or Excel, which is how the evidence leaves the system when somebody asks for it in writing.

ProAlert preventive maintenance compliance dashboard reading 96.3 percent against a 95 percent target, with 47 active schedules, 12 overdue and 15 due in the next seven days, a compliance breakdown by equipment category, a list of overdue preventive maintenance by how many days late, and a panel of three safety critical overdue items — **And the maintenance the auditor asks about next.** Preventive maintenance compliance across the whole plant: 96.3% against a stated 95% target, over 47 active schedules. The breakdown by equipment category is the part that answers the question properly, because a plant-wide average can hide a category that is failing. Twelve schedules are genuinely overdue and fifteen more fall due inside the next seven days, and the screen names them with their days late rather than rolling them into the percentage. Three of the overdue sit on safety critical equipment and get a panel of their own.

ProAlert 21 CFR Part 11 login audit trail over thirty days showing 457 sign-in attempts of which 408 succeeded and 49 failed, 323 sessions ended by an explicit sign-out, an 89.3 percent success rate, and a table of individual events each carrying its local timestamp, the account, whether it was a sign-in or a sign-out, whether it succeeded, the IP address it came from, whether it was a password or API authentication, the reason for any failure such as invalid password or user not found, and the client user agent, with filters for username, date range, status and row limit and buttons to export the whole period to CSV or Excel — **And the third row of the table above, with the evidence behind it.** Thirty days of access: 457 sign-in attempts, 49 of which failed, and 323 sessions closed by somebody actually signing out. The failures are the part that matters, because a log with a 100% success rate is a log nobody is really keeping. Each one names the reason the system gave at the time, so an invalid password on a floor terminal at 05:59 followed by a successful sign-in at 06:01 reads as what it is, and an attempt against an address that is not an account reads as something else. Every row carries the address it came from, and the whole period exports to CSV or Excel, not just the twenty-five rows on screen.

GAMP 5 Category 4: Under GAMP (Good Automated Manufacturing Practice) 5 guidelines, ProAlert is a configured product... a commercial software system customized through configuration, not code modification. Category 4 validation requires Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) documentation. ProAlert provides IQ/OQ/PQ templates as part of the implementation process for regulated manufacturers.

21 CFR Part 11 Compliance Features

21 CFR Part 11 is the FDA (Food and Drug Administration) regulation governing electronic records and electronic signatures in regulated industries. ProAlert's compliance layer covers the three core technical controls: audit trail, access management, and signature integrity.

Complete Audit Trail Compliance

Every data change across OEE records, DT (Downtime) calls, work orders, inventory transactions, scrap entries, and configuration changes is recorded with: the user who made the change, the timestamp of the change, the entity and field modified, and the before and after values. The audit trail is write-once and cannot be modified through the application interface. Capture and retention are in place today; a built-in screen for reviewing and exporting these records is in development, so retrieval is currently by query against the audit tables.

Every login attempt, successful session, and logout is recorded with user ID, timestamp, and IP (Internet Protocol) address. Failed login attempts are logged with the attempted username. Login records are available to administrators for access review and are included in the compliance audit trail export.

Password Policy Enforcement Compliance

Configurable password policy including minimum complexity (length, character classes), maximum age before required reset, and password history (prevents reuse of previous N passwords). Policy is enforced at the platform level and cannot be bypassed by individual users. Policy configuration itself is audit-trailed.

PIN-Verified Electronic Signatures

Call closures, work order sign-offs, and scrap threshold approvals require PIN verification tied to the individual user's account. The PIN prompt prevents shared-credential or unattended-terminal authorization. Each PIN verification creates a signed record with the user identity, timestamp, and action authorized.

The Quality Module: Nonconformance, Defects and Root Cause

Quality is part of the ProAlert Core platform, and it covers considerably more than the compliance controls above. It is the register a customer audit actually walks through.

Nonconformances That Raise Themselves

A nonconformance report appears from four sources without anyone retyping it: an audit finding, a failed inspection, a scrap-threshold violation, and a quality-dispositioned call. Each one links back to what caused it. A plain downtime call does not create one... that takes the Quality role and a disposition marked as creating an NCR, which is a workflow control rather than an accident waiting to happen.

Corrective Action on the Record

The CAPA card on a nonconformance is fillable: attach the root cause analysis and the corrective work order, or clear either. Estimated cost is stamped from the scrap count times the product cost, and an actual cost stays editable until the record closes.

Root Cause Analysis That Closes Its Loop

Start an investigation from the nonconformance that needs one and the source is pre-linked. A hierarchical 5-Why tree expands as far as the problem does, revising a countermeasure creates a version rather than overwriting it, and the record moves through submit, approve, request verification and verify effectiveness rather than simply being marked done.

Customer-Found Defects and External PPM

A register of defects the customer found after shipment, feeding external PPM (Parts Per Million) and raising the nonconformance behind it. Internal PPM sits beside it, shown as PPM where every product is countable and as a percentage with the reason stated where it is not, alongside a first-time-through tile on the daily management board.

FMEA Register

FMEA (Failure Mode and Effects Analysis) worksheets with line items, inline severity, occurrence and detection edits, calculated risk priority numbers, revised ratings after a countermeasure, and a type badge distinguishing process from design.

Change Requests

A change register linked from the nonconformance that prompted it, with approve, reject, verify and link-work-order actions, so a process change has the same traceable path as the defect that motivated it.

Scrap Threshold Governance

ProAlert's scrap governance system enforces configurable quality limits at the asset, product, and die cavity level... with supervisor approval workflows and real-time notifications when thresholds are crossed.

Component	How It Works
Scrap Threshold Configuration	Quality managers define acceptable scrap thresholds per asset, per product, and per die cavity. Threshold values are configurable at each level independently. A high-volume production die can have a tighter threshold than a prototype run. All threshold configurations are audit-trailed with the configuring user and timestamp.
Instant Scrap Email Notifications	The moment a scrap entry is recorded that exceeds the configured threshold, an email notification fires to the configured quality and supervisor recipients. Notification includes: asset name, product, die cavity, scrap quantity, threshold value, operator, and timestamp. No waiting for a shift-end report.
Threshold Approval Queue	Scrap events above threshold are placed in a supervisor approval queue. The queue is visible on the web admin and mobile app. Each queue entry shows the violation details and awaits supervisor disposition before the run can proceed. Time-in-queue is tracked for response time analysis.
Approval and Corrective Action Record	Supervisor approvals require a disposition selection (Approve Continue, Pull Die, Reduce Quantity) and a corrective action note. The completed approval record includes supervisor identity, PIN verification, timestamp, disposition, and notes. This record is attached to the original scrap event and included in the audit trail.
Quality OEE Integration	Scrap records feed directly into the Quality component of the OEE (Overall Equipment Effectiveness) calculation. Good parts vs. total parts is calculated in real time as scrap is entered. Threshold violations are visible in the live OEE dashboard alongside the Quality score that reflects them.

ProAlert scrap history filtered across all assets, showing a month of entries with the date and time, the asset, the product, the quantity scrapped, the scrap classification, and the operator note recorded against each one — **Every entry that the threshold rules read.** This is the record itself, not a summary of it: each row is a quantity against a named product on a named machine, classified and stamped, with the operator's own note attached. The notes are the part a monthly scrap total cannot reconstruct... a bend angle drifting after an adjustment, a thermocouple already replaced. Governance fires off these rows, and the Quality component of OEE is calculated from them.

Built-In Compliance vs. Compliance Add-On

Compliance Add-On Approach (Separate QMS Layer)

Separate QMS (Quality Management System) requires a separate integration with your OEE/CMMS platform
Audit trail covers only the QMS... OEE and maintenance actions not captured
Scrap records in the QMS vs. production records in OEE system must be manually reconciled
Two sets of user accounts, two password policies to maintain
Vendor must validate both systems and the integration between them
Typical QMS integration cost: $25,000–$75,000 in custom development

ProAlert Quality & Compliance

Single database: quality records and OEE/maintenance records share the same schema
Audit trail covers every module: calls, work orders, inventory, scrap, OEE, configuration
Scrap feeds directly into OEE Quality score with no reconciliation step
One user account, one password policy, one login audit log
Single system validation... GAMP 5 Category 4 documentation provided
Compliance integration cost: $0... same platform already running your floor

For IT, Quality, and Compliance Teams

Component	Technology	Notes
Audit Trail Storage	SQL Server AuditLog table (write-once)	Audit records written in a dedicated AuditLog table. Application-level security prevents modification through the ProAlert interface. Database-level backup and retention policies govern long-term audit record preservation.
Login Audit	SQL Server LoginAudit table, ASP.NET Core Identity events	Login events captured via ASP.NET Core Identity event hooks. Records persist to the database immediately... not buffered or written to application logs that can roll. Accessible to administrators through the Compliance section of the admin UI.
Password Policy	ASP.NET Core Identity PasswordOptions, configurable via admin UI	Password policy enforced at the Identity layer... cannot be bypassed at the application level. Complexity requirements, expiration interval, and history depth are all configurable without code changes. Policy changes are audit-trailed.
PIN Verification	Hashed PIN stored per user record, verified at signature prompt	PINs are stored hashed (not recoverable). PIN verification at call close, work order sign-off, and scrap threshold approval creates a SignatureRecord with user ID, action, entity reference, and timestamp. Records are included in the audit trail export.
Compliance Export	Audit trail CSV (Comma-Separated Values) / Excel export from admin UI	Administrators can export the full audit trail or filtered subsets (by date range, user, entity type) from the Compliance section of the admin interface. Exports suitable for submission to regulatory auditors without custom report development.

Prepare for your next quality audit before it's scheduled.

Book a 30-minute demo... we'll walk through the audit trail, login log, and scrap threshold workflow and show exactly what you'd hand an auditor.

Schedule a Demo