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 between users and the service is encrypted with TLS, terminated at Amazon CloudFront's edge. From there, requests travel to our load balancer in Mumbai over Amazon's network, encrypted again with TLS (version 1.2 or higher).
• 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 and servers. The database (Amazon RDS) and the disks of our application servers are encrypted at rest with keys managed by Amazon Web Services. (The server that held the database until 20 October 2026 was not encrypted at rest.)

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

Since 20 October 2026 the service runs on Amazon Web Services in Mumbai, India (the ap-south-1 region). The application servers and the PostgreSQL database that holds account and organisation records, monitoring metadata and report data are in that region, as is the endpoint that connected AI tools use. Requests reach the service through Amazon CloudFront, Amazon's global content-delivery network, which provides encryption in transit and protection against attacks: a request enters at the CloudFront location nearest the user and is forwarded to Mumbai. Generated reports and timesheets are stored in that PostgreSQL database. An earlier cache of generated reports and timesheets, a MongoDB database on the Hetzner server, has not been written to since mid-2026 and is no longer used; it will be removed with the rest of that server's production copy. The database runs on Amazon RDS with a standby copy in a second availability zone of that region, its storage is encrypted at rest, and automated backups are taken daily and kept for 14 days. We make no backup commitment beyond that.

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.

Before 20 October 2026 the service ran on one server operated by Hetzner in Falkenstein, Germany. That server now runs our staging environment and the demo workflow on our website; the production copy of the database and the earlier report cache that were on it are to be removed (to be confirmed). Cloudflare provides domain name service for our domains and sits in front of the hosts that remain on that server.

The core of the service, including the database, runs in one Amazon Web Services region (Mumbai). The database runs on Amazon RDS with a standby copy in a second availability zone, is not reachable from the internet and has deletion protection enabled; the application runs on two servers in an auto-scaling group. Automated backups of the database are taken daily and kept for 14 days, with point-in-time restore within that window. There is no backup copy in another region, and we have not yet documented a restore rehearsal. A failure affecting the whole region would interrupt the service. 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 held in AWS Systems Manager Parameter Store and supplied to our services when they start; they 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.

• A documented restore rehearsal and an off-region backup copy. Automated database backups are in place (daily, kept for 14 days). We have not yet rehearsed and documented a restore, and keep no backup copy outside the Mumbai region.
• 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.
• 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.
• Central application log collection. Infrastructure logs (database, network) are kept for 365 days; application logs stay on each server's local disk without rotation and are lost when a server is replaced.
• Availability measures. A status page, uptime monitoring with an on-call rota, and an uptime commitment.

Questions about this page: support@screenjournal.ai.