Security

This page describes the technical and organisational measures that Cyberinfra Limited ("ScreenJournal", "we") applies to the ScreenJournal service today. We describe what is built and running now. Where a measure is not yet in place we say so in the section concerned, and section 11 lists every such gap in one place. Roadmap items are plans, not commitments.

1. Data minimisation by design

• Sensitive applications excluded before capture. Each organisation has a blocklist of applications and sites that are never recorded, and sensitive-category packs (banking, payroll, HR, health and adult content) are switched on by default. Windows that match are excluded before capture, so they are not recorded or sent for analysis. An organisation's administrators can change these settings.
• Derive and discard in the default capture mode. In the default mode, short screen recordings are uploaded for analysis and deleted after analysis; any temporary copy is removed by a storage lifecycle rule we configure on the bucket. What we keep is the derived activity timeline: application names, window titles, sites, descriptions and scores, and, where an organisation enables audio, the audio recordings and transcripts.
• Stored video on our servers only where the employer elects it. Two features keep screen video on our servers, and both are the employer's choice: Record + Save, which keeps the recording of every segment, and alert evidence clips, which keep the clip behind an alert. If an organisation uses either, stored screen video exists for its members. Separately, the desktop app keeps recordings on the member's own device for the period the organisation sets (up to three months) before removing them.
• Output redaction. Before analysis output is stored, an automated filter removes secrets and certain identifiers from activity descriptions and window titles: private keys and access tokens, payment card numbers (checked with the Luhn checksum), US social security numbers and phone numbers. Names, email addresses and web addresses are kept, because they give the record its meaning.
• No biometrics. The service performs no face recognition, voiceprints or emotion recognition. Transcripts attribute each passage to the member or to the other party; the transcription model may also label a passage with a name spoken in the conversation, and that label is stored with the transcript. No voice is matched against a voiceprint and no one is identified biometrically.
• Audio off by default. Audio capture is off unless an organisation's administrator turns it on.

2. Encryption

• In transit. Traffic to the service is encrypted with TLS. Cloudflare terminates TLS at its edge, and Caddy serves TLS on our server.
• At rest, object storage. Activity data in Amazon S3 and media in Google Cloud Storage are encrypted at rest by those providers' default server-side encryption, with keys managed by the provider.
• At rest, database. The disk of the server that holds our database is not encrypted at rest (checked 5 October 2026).

We do not operate our own key-management service.

3. Access control

Built today:

• Sign-in. Members can sign in without a password, by an emailed link or one-time code, or with Google or Microsoft. Sign-in links and one-time codes expire after five minutes. Password sign-in is also available; passwords are stored as salted hashes, and passwords known from public breaches are refused.
• Two-factor authentication. Any member can turn on two-factor authentication with an authenticator app. It is optional.
• Sessions. Each member can see a list of their signed-in sessions, with device and IP address, and can revoke any one of them or all others at once.
• Roles. Access inside an organisation follows a role model (owner, administrator, managers and members). What a person can see is limited to their role and, for managers, to the people they manage.
• Support access by our staff. When a member of our platform staff signs in as a member to investigate a support issue, that session is marked as an impersonation in the member's own session list.

Not yet built: single sign-on (SAML or OIDC), two-factor authentication enforced by the organisation, and a central access log. Staff access is not yet centrally logged: apart from the session-list marker above, we keep no separate record of what our staff view.

4. Tenant isolation and service security

• Organisation-scoped data. Stored data is keyed by organisation and user, and every query is scoped to the caller's organisation. The scope comes from the caller's verified token, never from the request body, and identifiers are validated before they are used to build a storage path.
• Signed, short-lived tokens. Our services accept only signed, short-lived access tokens, which they verify against our published key set; unsigned tokens and tokens signed any other way are refused. A failed check returns a generic error, and the detail is logged only on our side. Redaction deletes are accepted only with a token our account service issues for that purpose, after it has checked the organisation's redaction settings.
• Capture upload path. The upload path for captured activity data requires a dedicated secret in addition to a valid token, and the secret is compared in constant time.
• Demo organisations. Public demo organisations are read-only: every write is refused.
• Connected AI tools. An organisation can connect its own AI tools through our integration feature. Those tools act under the organisation's authorisation and are recipients the organisation chooses.

5. Hosting, availability and backups

The service runs on one server operated by Hetzner in Germany, with Cloudflare in front of it for traffic protection and encryption in transit. Account and organisation records, monitoring metadata and report data are held in a PostgreSQL database on that server, and generated reports are cached in a MongoDB database on the same server. The server also runs other applications we operate, in separate containers. We do not currently keep database backups.

Activity time-series data is stored in Amazon S3 in Mumbai, India (the ap-south-1 region). Since August 2026 all new screen and audio media is stored in Google Cloud Storage (region to be confirmed); older media remains readable in Amazon S3 in Mumbai. The AI analysis of screen recordings and audio runs on Google Gemini models through Google's Vertex AI service at its global endpoint. Report and timesheet narratives, alert evaluation and the assistant use Google Gemini models through Google's Gemini API, as does the support chat on our website.

The core of the service, including the database and the report cache, runs on that server in Falkenstein, Germany, alongside other applications we operate in separate containers. A failure of that server would interrupt the service, and because we do not currently keep database backups, data held only in the database could be lost. Object storage in Amazon S3 and Google Cloud Storage relies on those providers' own redundancy.

We make no uptime commitment. We do not publish a status page, and we do not run an on-call rota. Crash and error reports from the desktop app reach us through Sentry, but our servers have no automated uptime or error alerting.

The full list of the third parties that process data for us, with their locations, is on the Subprocessors page.

6. Retention and deletion

Data is retained for the term of your employer's subscription unless it is deleted earlier on a verified request or by your employer. Where Record + Save is enabled, stored screen video is kept for up to three months by policy. Automated expiry is not yet built; deletion is carried out by our operational procedure.

Where an organisation allows it, members or managers can redact a time range. Redaction deletes the activity data and stored video for that range, and we keep a record of each redaction (who asked, which range, and when). Alert evidence clips are not removed by a member's redaction request.

An organisation can set a retention period for alert evidence clips, but no automated process yet applies it; until one exists, clips remain stored until they are deleted under our operational procedure. Per-category detail is in our Retention & Deletion Protocol.

7. Subprocessors and AI

Our subprocessors, what each one processes and where, are listed on the Subprocessors page, which also explains how we announce changes to that list.

Google states that it does not use customer content submitted through Vertex AI to train its foundation models. We do not make that statement on behalf of any other vendor. For the Gemini API, which serves reports, alerts and the assistant, Google's terms state that content submitted under its paid services is not used to improve Google's products; whether all of our usage falls under those paid-service terms is to be confirmed.

Sentry (desktop crash reports), Telegram (forwarding bug reports to our staff) and our email providers, Resend and Google Workspace, operate under their standard terms of service. Crash reports can include window titles, and bug reports include the reporter's email address and the text they wrote.

8. Incident response

What exists: a written incident-response plan, covering how we classify, contain and investigate an incident and whom we notify.

What does not exist yet: dedicated detection tooling (such as central log monitoring or intrusion alerts) and an on-call rota. In practice, incidents reach us through errors we see, reports from customers and reports from researchers.

When we confirm an incident affecting an organisation's personal data, we notify the affected organisations without undue delay, with what we know, so they can meet their own obligations.

9. Reporting a vulnerability

If you believe you have found a security vulnerability in ScreenJournal, email support@screenjournal.ai with a description and the steps to reproduce it. Please give us a reasonable time to fix the issue before you disclose it publicly, and do not access, change or delete data that is not yours.

Our contact details for security reports are also published in machine-readable form at /.well-known/security.txt. Our full Vulnerability Disclosure Policy sets out scope, safe harbour and how to report.

10. Secure development

• Code review. Changes are usually made through pull requests that another person reviews. Review is our normal practice, but not every change is reviewed before it is merged.
• Automated checks. Automated tests and checks run in continuous integration on pull requests. Our backend services also run automated dependency vulnerability scans on every pull request and on changes to the main branch.
• Secrets. Service secrets and provider credentials are supplied to our services through configuration held on the server, and are not stored in our source code.
• No penetration test yet. No independent penetration test has been carried out.

11. Roadmap and not yet built

The following are not in place today. We list them so that customers can assess the service as it is.

• Database backups and a tested restore procedure. We do not currently keep database backups.
• Automated retention. No process yet deletes data automatically when a retention period ends.
• Central access and audit log. No central log records access to customer data, including access by our staff.
• Single sign-on and organisation-enforced two-factor authentication.
• Database disk encryption. The server's disk is not encrypted at rest.
• SOC 2 report. We track our security controls in Vanta and are preparing for a SOC 2 audit. No SOC 2 report or ISO 27001 certificate has been issued.
• Penetration test. None has been carried out.
• Detection tooling. No central log monitoring or intrusion alerting is in place.
• Server error alerting. Our servers have no automated uptime or error alerting.
• Availability measures. A status page, uptime monitoring with an on-call rota, and an uptime commitment.

Questions about this page: support@screenjournal.ai.