An auditor asks who, when, and on what basis

Electronic signature

Signing works at two levels. System approval covers everyday steps. At the electronic signature level the user re-enters their password; without verification no signature record is created.

When a signed operation is performed, the signature is checked to confirm that:

• the signature actually exists,
• it belongs to the record being acted on — a signature on another record cannot authorise it,
• it was made by the person performing the operation,
• identity was re-verified (a password was requested),
• its meaning is approval — a rejection cannot publish anything.

The signature record stores who signed, with which authentication method, against which content hash, with what meaning, and from which IP and device. Signature records are append-only; no update or delete endpoint is exposed.

Audit trail

• Quality records and session/access records are never physically deleted; soft deletion is used. Short-lived secrets such as refresh tokens are the exception and are removed permanently.
• Data changes are written to the audit trail, access and export events to the security log.
• Authorisation history is kept: when a permission is granted to or revoked from a user, the security log records who changed what for whom, when, and from which address.
• Rejection, cancellation and withdrawal decisions require a reason, which is written into the trail.
• Audit trail entries are sealed with a hash chain; integrity is verified regularly and every verification run leaves its own record.

Authorisation

Authorisation is role-based and combined with record-level scope: a user only sees records for the companies, sites, units and processes in their scope. The scope filter is applied in the query layer — hiding things in the interface is not considered sufficient.

Account security

• Two-factor authentication (TOTP), recovery codes, trusted devices.
• Account lockout after failed attempts; the login screen reports remaining attempts.
• Session revocation is enforced: a revoked session token is rejected on the next request.
• Rate limiting on identity endpoints; security headers, and HSTS in production.

Data and regulation

In the cloud deployment data is hosted in Türkiye; organisations that prefer it install on their own servers. Turkish data protection (KVKK) requirements — notice, retention periods, access logging — are reflected in the data model.

What we do not claim

The product helps you operate the controls required by ISO 9001 and related standards; certification is granted to your organisation, not to software. Likewise, controls aligned with 21 CFR Part 11 and GAMP 5 expectations — authenticated signatures, an immutable trail, mandatory reasons — are built into the design, but the full computer system validation package for pharmaceutical and medical device use is separate work carried out for your specific installation.