Security, data and the supplier record

Transport encryption

In place

All public traffic is served over HTTPS with a strict transport security header, subdomains included and preload set: two years on this website, one year on the API and the automation service, where the network provider in front of them sets it. You can read the header on the response for this page.

GDPR Art. 32(1)(a)

Minimum TLS version

In placemeasured 20 September 2026

TLS 1.2 is the floor on every public hostname: TLS 1.0 and 1.1 handshakes were refused when measured on 20 September 2026. The setting belongs to the hosting providers, so it is measured again at every quarterly drill. You can check it by offering TLS 1.1 with an SSL client.

GDPR Art. 32(1)(a)

Identifiers before they reach a log

In place

Directory identities are replaced with a keyed one-way digest (HMAC-SHA-256 under a server key) before anything is logged. This is pseudonymisation under Article 4(5): ITSailor holds the key, so the log data remains personal data.

GDPR Art. 32(1)(a)

Short-lived tenant scan results

In place

A free-tool scan result is kept for up to ten minutes, encrypted with AES-256-GCM under a key the database provider does not hold. Without the key the scan does not start, and there is no plaintext fallback. The database runs in Ireland, inside the EEA.

GDPR Art. 32(1)(a)

Off-site backups encrypted at rest

In place

Each backup bundle is encrypted on the host before it leaves, to two keys whose private halves are not on that host: one is in a password manager, one on an offline drive. Environment files stay out of the bundle. Database dumps travel inside it, so stored credentials are carried as ciphertext and password hashes.

GDPR Art. 32(1)(a), DORA Art. 12(2)

Encryption at rest of the production database volume

Not in place

Not implemented. The databases run in containers on one server with no disk or volume encryption, so a physical or hypervisor-level compromise is not mitigated.

GDPR Art. 32(1)(a)

Network exposure

In place

Applications are published through an outbound-only tunnel, and no application port is reachable from the internet. SSH is the only service on the production host that accepts traffic from the internet, read off the host on 21 September 2026.

GDPR Art. 32(1)(b), NIS2 Art. 21(2)(i)

Remote administrative access

In place

SSH by public key only, through a named non-root account. Root login and password authentication are disabled, and repeated failures from one source are banned automatically.

GDPR Art. 32(1)(b), NIS2 Art. 21(2)(i)

Patching

In place

Operating system security updates install automatically. Restarts do not, so a kernel fix waits for a manual reboot. Application images are pinned to exact versions, so a rebuild reproduces what runs.

GDPR Art. 32(1)(b), NIS2 Art. 21(2)(e)

Browser-side hardening

In place

Every response from this website carries a content security policy, nosniff, a frame-ancestors restriction, a referrer policy and a permissions policy. The policy allows inline script, so the defence against injected script is sanitising untrusted HTML where it is rendered. The API sends its own policy; the automation service sends nosniff only.

GDPR Art. 32(1)(b)

Abuse and brute-force control

In place

Sliding-window rate limits on sign-in, password reset, public forms, the consent record, checkout and document rendering. If the limit store is unreachable, checkout and document rendering fall back to a count kept by each server instance, and public forms are accepted without a limit.

GDPR Art. 32(1)(b)

Change control

In placeas a convention, not as an enforced control

Every change to the production website goes through a pull request with the automated gate. The gate reports and does not block: no repository ruleset or code-owner rule enforces it.

GDPR Art. 32(1)(b), NIS2 Art. 21(2)(e)

Availability monitoring

In place

External monitors run by UptimeRobot check the API, the customer portal, this website and the automation service every five minutes and alert by email. The results are on a public status page.Open the status page

GDPR Art. 32(1)(b), NIS2 Art. 21(2)(b)

Availability service level

Not in place

None is offered. UptimeRobot publishes the observed uptime of each monitored service on the public status page. ITSailor commits to no level and publishes no figure of its own.Open the status page

GDPR Art. 32(1)(b)

Security event detection and alerting

Not in place

No central log aggregation, no security information and event management system, and no alerting on security events. Alerts cover availability only, so a security event is found when someone looks.

GDPR Art. 32(1)(b), NIS2 Art. 21(2)(b)

Backup state alerting

In place

An external monitor expects every scheduled backup run: a failure, or a run that never starts, raises an email alert. A forced failure proved the alarm on 28 August 2026. The alert reaches one person, and the credential that reports health sits on the production host, so a compromise of that host could report a healthy run that did not happen.

GDPR Art. 32(1)(b), DORA Art. 12(2)

Server-side logging

Partial

Structured logging with stable event names exists through a shared module. Most server logging is still plain console output.

GDPR Art. 32(1)(b)

Log integrity

Not in place

No write-once or tamper-evident log storage is operated.

GDPR Art. 32(1)(b)

Automated twice daily backup

In place

At 03:00 and 15:00 Malta time both production databases, the uploads and the automation data are bundled and shipped off-site to a storage box in Falkenstein, Germany. A bundle from this schedule was restored onto a replacement machine on 20 September 2026.

GDPR Art. 32(1)(c), DORA Art. 12(1)(a)

A copy the production host cannot delete

In place

Daily provider-side snapshots, which the production host holds no credential to create, change or delete. Tested on 11 August 2026: a file deleted by the backup identity was recovered from a snapshot with a matching digest. The recovery window is bounded by the number of snapshot slots.

GDPR Art. 32(1)(c), DORA Art. 12(3)

Documented restore procedure

In place

A restore script and a step-by-step procedure exist, from stopping the services to checking that both health endpoints answer.

GDPR Art. 32(1)(c), DORA Art. 12(1)(b)

Geographic separation of the off-site copy

Not in place

The off-site copy is in the same location as the production host, with no second region and no second provider, so a regional loss takes both.

GDPR Art. 32(1)(c), DORA Art. 12(2)

Recovery point objective

Not in place

None is committed. Two runs a day bound the loss at twelve hours. The rebuild of 20 September 2026 lost ten hours of database change and no files.

GDPR Art. 32(1)(c), DORA Art. 12(6)

Recovery time objective

Not in place

None is committed. The rebuild of 20 September 2026 took one hour and twenty-five minutes against an internal target of eight hours. It is one sample, with the bounds stated in the drill record on this page.

GDPR Art. 32(1)(c), DORA Art. 12(6)

Automated gate on every change

In placeas a reporting gate

Every pull request and every push to main runs the linter, a type check, the full test suite, a production build, a prerender check, a bundle budget and a secret guard.

GDPR Art. 32(1)(d), NIS2 Art. 21(2)(e)

Tested controls, not only tested code

In place

Tests in the gate fail when the published connector permissions differ from what the connectors request, when the sub-processor list and the Privacy Policy disagree, or when a page makes a claim the claim gate bans.

GDPR Art. 32(1)(d)

Dependency inventory

In placefrontend package tree only

A CycloneDX software bill of materials of the frontend package tree is produced weekly from the main branch and on demand. The container images on the production host are not in it.

GDPR Art. 32(1)(d), NIS2 Art. 21(2)(e)

Dependency vulnerability scanning

In place

Grouped update pull requests for the application, the scripts, the pipeline actions and the pinned images, and a weekly audit against two advisory databases. A high or critical finding in code that reaches a user turns the security scan red; findings in container images and development-only packages report. Three of the scanned images are configured on the production host and scanned from a version list transcribed in June 2026, so a clean result proves that list rather than the running images. There is no static analysis of the code ITSailor writes.

GDPR Art. 32(1)(d), NIS2 Art. 21(2)(e)

Restore proved

In placetwo dated events, one of them a rebuild from nothing

On 11 June 2026 a database restore ran on the production host. On 20 September 2026 the whole estate was rebuilt from one encrypted off-site bundle on a throwaway machine and reconciled by row and file count. Production was not modified.

GDPR Art. 32(1)(c), DORA Art. 12(2)

Recurring restore drill

Partial

The first drill ran on 20 September 2026. The programme is quarterly, and one drill is a single data point: the second is due 11 December 2026.

GDPR Art. 32(1)(d), DORA Art. 11(6)

Penetration testing

Not in place

None has been performed, so no report exists to offer or summarise.

GDPR Art. 32(1)(d)

Periodic access review

Not in place

There is no documented periodic review of which provider console holds which access.

GDPR Art. 32(1)(d), NIS2 Art. 21(2)(i)

Vulnerability reports from outside

In place

A security contact is published under RFC 9116, with the scope and the safe harbour on this page.

NIS2 Art. 21(2)(e)

People with access to customer personal data

In place

One. There are no employees, and no contractor holds standing access to production systems or customer data.

GDPR Art. 32(1)(b), DORA Art. 29

Separation of duties

Not in placestructural, and disclosed

Not possible in a one-person business: the same person writes, reviews, approves and deploys a change. The automated gate is the only independent check before production.

GDPR Art. 32(1)(b), DORA Art. 29

A second operator

Not in placestructural, and disclosed

There is none. The service, and any restore, depend on one person and on that person's password manager. Record it as concentration risk.

DORA Art. 29, NIS2 Art. 21(2)(d)