Every control here answers a specific clause. Filter by the quality process that performs it or the GxP discipline it bears on, and follow any card through to the risk it reduces or the record it produces.
Specify what the system must do, verify it against that specification at a depth justified by risk, and release it under an approved validation summary before regulated use begins.
Assess each system for its impact on patient safety, data integrity and product quality, and justify the validation and control effort from that assessment rather than applying one depth to everything.
Issue each individual their own account and forbid shared or generic logins, so every entry and change in the system resolves to one named person.
Grant privileges from a defined role model on documented authorisation, and withdraw them when the role changes or the person leaves — not at the individual’s discretion.
Compare the system’s actual account and privilege list against current authorised roles at a defined interval, and record the removals and corrections the comparison produces.
Configure the system to verify that the person attempting an action is authorised for that specific action — signing, altering a record, or operating a device — rather than merely authenticated.
Keep every identification code and password combination unique to one individual, revise credentials on a defined cycle, and operate a documented procedure for loss, compromise and deauthorisation of tokens or devices.
Enable a secure, computer-generated, time-stamped audit trail that records who did what and when without obscuring the previous value, and configure it so users cannot disable or edit it.
Have a competent person review audit-trail entries at a risk-based frequency, record what was examined, and disposition anomalies — an enabled trail nobody reads detects nothing.
Provide a means to generate copies of regulated records in both human-readable and electronic form, complete with the metadata and audit trail that make them meaningful, for inspection and for the agency’s own use.
Back up regulated data on a defined cycle and periodically restore it to confirm the restored data is complete and accurate — a backup that has never been restored is an assumption, not a control.
Protect regulated records so they remain accurate and retrievable throughout the retention period, with archived data secured against loss or alteration for as long as it must be kept.
Periodically retrieve archived data and confirm it can still be rendered and interpreted, migrating format or application where obsolescence would otherwise make a retained record unreadable.
Configure the system to enforce permitted step sequencing where sequence matters, so an operation cannot complete before its prerequisite step has actually been performed and recorded.
Where only certain terminals or instruments may supply data, configure the system to verify the source of an input, so data entering the record cannot originate from an unqualified device.
Build in checks on data exchanged electronically between systems, and verify them, so a transfer that silently truncates, reorders or drops records is detected rather than trusted.
Independently check critical data entered by hand — by a second person, or by a validated system check whose adequacy is justified and documented.
Establish that everyone who develops, maintains or uses a regulated system has the education, training and experience their specific tasks require, and keep the record current.
Document who owns, operates, administers and provides IT support for each regulated system, so authority and accountability are assigned rather than assumed.
Issue and have individuals acknowledge a written policy holding them accountable for actions taken under their electronic signature, so its use is deterred from falsification.
Verify the identity of each individual before issuing an electronic signature, keep each signature unique to one person and never reassigned, and certify to the agency that electronic signatures are the legally binding equivalent of handwritten ones.
Configure non-biometric signatures to use two distinct identification components, require both for a signing executed outside a single continuous session, and ensure a signature can only be used by its genuine owner.
Ensure the signed record displays the signatory’s printed name, the date and time of signing, and the meaning of the signature — review, approval, responsibility or authorship — in the same human-readable form as the record itself.
Link each electronic signature to its record so it cannot be excised, copied or transferred to another record to falsify one — the binding, not the credential, is what makes the signature meaningful.
Where the people responsible for the record content do not control system access, add measures such as document encryption and appropriate digital signature standards on top of the closed-system controls, to keep records authentic, intact and confidential from creation to receipt.
Control distribution of, access to, and revision of the operating and maintenance documentation for a system, and keep an audit trail of its revision and change history over time.
Assess, approve, implement and verify every change to a regulated system through a controlled process, so no configuration, version or interface changes without the validated state being re-established.
Record the released configuration and version of each regulated system and keep an up-to-date inventory of them, so an unplanned change is detectable against a known baseline rather than against memory.
Evaluate each regulated system at defined intervals against its change, incident, access and audit-trail history, and confirm — or restore — its continued validated state and fitness for purpose.
Assess the competence and reliability of suppliers and service providers before relying on them, define the quality obligations in a formal agreement, and re-evaluate on a risk-based cycle.
Report system failures and data anomalies, assess their impact on product quality and record integrity, investigate root cause, and close the actions out — treating a repeat incident as an ineffective action, not bad luck.
Define an alternative arrangement for continuing each critical process during system unavailability, scale it to the consequence of the outage, and exercise it so the arrangement is known to work before it is needed.
Where a system is used to certify and release batches, restrict that action to the authorised person and record clearly who released each batch, so release authority is enforced by the system rather than by convention.
The requirement statements are faithful restatements of the regulations they cite, each carrying its clause and source. The controls, risks, evidence types and processes — and every line drawn from an obligation to a control — are SPEQ synthesis: a practitioner’s reading of how an obligation is customarily discharged. No regulator publishes this mapping. 21 CFR 11.10(d) requires that system access be limited to authorised individuals; it does not say “run a quarterly access review”. That inference is what SPEQ adds, and it is labelled rather than presented in a regulator’s voice.