To prove authorization during an audit, capture evidence that the person was allowed to perform the specific action at the time it occurred. A name and timestamp are usually not enough. The record should connect the user, the action, the controlled object, the applicable revision, the approval basis, and the user’s authority at that point in time.
The practical test is simple: an auditor should be able to see not only that someone approved, released, changed, accepted, or overrode something, but also why that person was authorized to do it under the site’s defined process.
Core data to capture
- User identity: unique user ID, display name, and, where relevant, employee or contractor identifier. Avoid relying on shared accounts.
- Action performed: approval, release, disposition, deviation acceptance, electronic signature, override, access grant, training signoff, or record change.
- Date and time: timestamp with time zone or controlled system time. Clock synchronization matters when events cross MES, ERP, PLM, QMS, or maintenance systems.
- Object affected: work order, traveler, operation, inspection record, NCR, CAPA, drawing, specification, route, batch record, maintenance task, or document number.
- Revision or version: the exact revision of the instruction, drawing, specification, workflow, or record that was approved or used.
- Authority basis: role, permission group, job function, certification, training qualification, approval matrix, delegation, or named assignment that allowed the action.
- Effective dates: when the role, qualification, delegation, or permission became active and, if applicable, when it expired.
- Workflow state: status before and after the action, such as drafted, reviewed, approved, released, rejected, reopened, or superseded.
- Authentication evidence: login session, electronic signature event, multi-factor authentication event, or other validated authentication mechanism where required by the process.
- Reason or comment: especially for overrides, deviations, manual changes, rework dispositions, and exception approvals.
- System of record: the application where the authoritative event occurred, such as MES, QMS, ERP, PLM, LIMS, CMMS, or document control.
- Audit trail linkage: immutable or controlled audit trail entries that connect the event to the user, timestamp, object, and previous value where data changed.
Authorization depends on context
The required evidence depends on the process being audited. Authorization for a production operator to complete an operation is not the same as authorization for a quality engineer to disposition a nonconformance, an engineer to release a routing change, or an administrator to modify user permissions.
In regulated manufacturing, the strongest evidence usually comes from a combination of system permissions, training records, role assignments, document control, and workflow history. No single data field proves authorization by itself if the surrounding process is weak or poorly controlled.
Common failure modes
- Shared accounts or generic logins that make individual accountability unclear.
- Permissions that show the user is authorized today but do not show whether they were authorized when the action occurred.
- Role changes without effective dates or approval history.
- Training records that are not linked to the operation, document revision, or qualification requirement.
- Manual approvals in email or spreadsheets that are not controlled as records.
- Audit trails that can be edited, purged too early, or separated from the production or quality record.
- Inconsistent user identities across MES, ERP, PLM, QMS, and maintenance systems.
- Time stamps from unsynchronized systems, making event sequence difficult to defend.
Brownfield system reality
Many plants do not have one clean authorization source. MES may control execution, ERP may own work orders, PLM may own engineering release, QMS may own nonconformance and CAPA, and training may live in a separate LMS or HR system. In that environment, authorization evidence often has to be assembled from multiple systems.
Full system replacement is usually unrealistic in regulated brownfield operations because of validation cost, qualification burden, downtime risk, integration complexity, traceability obligations, and long equipment lifecycles. A more practical approach is to define which system is authoritative for each authorization decision, preserve audit trails, map user identities, and control interfaces under change control.
What auditors usually look for
Auditors typically look for consistency between the written procedure, the system configuration, the user’s role or qualification, and the actual record. If the procedure says only certified inspectors can accept a characteristic, the evidence should show that the named inspector had that certification and permission when the acceptance occurred.
This does not guarantee an audit outcome. Evidence quality still depends on validation, configuration discipline, retention settings, access control design, and whether people follow the controlled process instead of bypassing it.