Data Protection & Security

1. Access control

• Role-based permissions. Every user has one or more roles. Each role carries an explicit set of permissions per module and action (view, create, edit, delete and approve). Nothing is granted by default, and menus only show what a role can open.
• Branch scoping. A role can be limited to one branch, so staff at one site cannot browse another site's records.
• Every request is checked on the server. Permissions are enforced on each page and action, not just hidden in the menu.
• Least privilege for administrators. Only one built-in role (Super Admin) bypasses permission checks. Facilities are encouraged to keep it to as few people as possible.
• Deactivation, not deletion. When someone leaves, their account is deactivated immediately while their history stays in the audit trail.

2. Sign-in and sessions

• Passwords must be at least 10 characters and are stored only as a one-way bcrypt hash. Nobody, including us, can read them.
• New accounts and admin-reset passwords must be changed at first sign-in.
• Repeated failed sign-ins from the same address are throttled (5 attempts per minute), and failed attempts are logged.
• The session identifier is regenerated at sign-in to prevent session fixation, and idle sessions expire after two hours.

3. Encryption

• In transit: all traffic between browsers and the servers uses HTTPS (TLS), including between our edge network and the origin server.
• Sensitive identifiers at rest: national ID numbers are encrypted in the database with an application key held outside the database, and they are encrypted in audit records too.
• Passwords: one-way hashed (see above).

4. Audit trail

Every time a record is created, changed or removed, GomoClinic stores who did it, which branch they were working in, what changed (before and after), when, and from which IP address and device. Sign-ins, sign-outs and failed sign-in attempts are recorded too. Secrets such as password hashes are redacted from audit entries. Facilities can use the trail to investigate any question about who did what.

5. Application security

• Cross-site request forgery protection on every form and action that changes data.
• A strict Content Security Policy: pages only run scripts and styles served by GomoClinic itself, which blocks most injected-script attacks.
• Security headers that stop pages being framed by other sites, block content-type sniffing and limit referrer information.
• Output escaping of everything users type before it is shown, and parameterised database queries throughout.
• Uploads (photos, documents and images) are stored outside the public web folder and served only to users with permission.

6. Infrastructure and operations

• Servers sit behind a firewall and an edge network that absorbs malicious traffic; only web and administrative ports are open.
• Deployments are automated and versioned, so a faulty release can be rolled back quickly.
• Access to production servers is limited to named engineers, and automated deployments run under a dedicated account that has only the system rights deployment needs.
• The data location and backup arrangements for each facility are set out in its service agreement.

7. People and process

• Every user is bound by the Confidentiality & Staff Code.
• Our engineers access facility data only to operate or fix the system, never to browse it.
• Incidents are handled under the Incident & Breach Response policy.

8. What facilities should do

Security is shared. We recommend that every facility:

• gives each person their own account, and never shares logins;
• reviews roles and permissions regularly, and deactivates leavers on their last day;
• locks screens or signs out on shared computers;
• keeps printed records (receipts, results, letters) as securely as the electronic ones.

9. Reporting a vulnerability

If you believe you have found a security weakness, email [email protected]. Please do not access other people's data or disrupt the service while testing.