Data Processing Agreement

SCREENish Data Processing Agreement

Version 1.2 — published 17 September 2026, effective 19 October 2026. Version 1.1 (published 5 September 2026, announced for 5 October 2026) is superseded by this version before taking effect; Version 1.0 (effective 3 September 2026) applies until then.

What changed in version 1.2. Published under clause 14.2 with 30 days' notice; the Terms of Service are unchanged. (1) Clause 3.6 adds application programming interface keys, webhook addresses, feed addresses and connected third-party tools to the transmissions that are made on the Customer's instruction. (2) Annex II describes the measures that apply to API access and outbound connections where they are offered. (3) Annex IV records the Customer's responsibility for the recipients it connects. Nothing in this version permits any route to carry the categories named in clause 3.5.

What changed in version 1.1 (carried into version 1.2). Published under clause 14.2 with 30 days' notice; the Terms of Service are unchanged. (1) Annex II now describes the support session through which one authorised SCREENish role can open a user's account for support, with a mandatory reason, an audit record and a notification on every use; clause 4.2 refers to it. (2) Annex I.C, I.E and II describe diagnostic records: log files the tracking application can upload from an employee's device for support, only where the Customer has enabled it and only against an open, recorded request. (3) Annex I.E adds retention periods for profile photographs, diagnostic records, server and application logs, audit records and database backups. (4) Annex II states the exact exposure of profile photographs, that they are encrypted at rest and that the previous photograph is deleted on replacement. (5) Annex IV records that older client generations which cannot be updated do not carry all the measures of the current one, and what has been built to make the capture settings issued for a frame traceable. (6) Annex III.B states the roles of Braintree/PayPal (independent controllers) and inv.bg (processor, EEA only).

This Data Processing Agreement (the "DPA") forms part of, and is incorporated by reference into, the SCREENish Terms of Service (the "Agreement") between:

(1) the customer that has subscribed to the Services (the "Customer"); and

(2) SCREENish LTD, a company incorporated in the Republic of Bulgaria with registered address 2a Angel Kanchev Street, 3rd floor, 4000 Plovdiv, Bulgaria, UIC 205586868 (VAT BG205586868), operating the SCREENish platform ("SCREENish").

Each a "party" and together the "parties".

This DPA applies where SCREENish processes Personal Data on behalf of the Customer in the course of providing the Services. It takes effect on the date the Customer accepts the Agreement or first uses the Services, whichever is earlier, and applies to all such processing from that date.

1. Definitions

1.1 "GDPR" means Regulation (EU) 2016/679, and, where applicable, that Regulation as it forms part of the domestic law of the United Kingdom.

1.2 "Personal Data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority" have the meanings given in the GDPR.

1.3 "Customer Personal Data" means Personal Data that SCREENish processes on behalf of the Customer under the Agreement, as described in Annex I.

1.4 "Sub-processor" means any processor engaged by SCREENish to process Customer Personal Data on the Customer's behalf.

1.5 "Services" means the SCREENish workforce time-tracking and activity-monitoring platform, including the desktop and mobile tracking applications and the web dashboards.

1.6 "Standard Contractual Clauses" or "SCCs" means the standard contractual clauses for the transfer of personal data to third countries adopted by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021.

1.7 "Data Protection Law" means the GDPR and any other data protection or privacy law applicable to a party's processing under the Agreement.

2. Roles of the parties

2.1 The parties acknowledge that, in respect of Customer Personal Data, the Customer acts as controller and SCREENish acts as processor.

2.2 The Customer determines the purposes and means of the processing. In particular, the Customer decides whether to monitor its personnel, which individuals are monitored, and with what capture settings. Annex IV records the decisions that rest with the Customer.

2.3 Monitored individuals are data subjects but are not party to the Agreement. Their rights are exercised against the Customer as controller, and clause 7 governs how SCREENish assists.

2.4 Where SCREENish processes Personal Data as a controller in its own right — for example account administration, billing, and security logging necessary to operate the Services — that processing falls outside this DPA and is governed by the SCREENish Privacy Policy.

2.5 Nothing in this DPA makes SCREENish a joint controller with the Customer.

3. Processing on documented instructions

3.1 SCREENish shall process Customer Personal Data only on the Customer's documented instructions, including with regard to transfers to a third country, unless required to do so by Union or Member State law to which SCREENish is subject. In that case SCREENish shall inform the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

3.2 The Agreement, this DPA (including its Annexes), and the configuration the Customer selects within the Services together constitute the Customer's complete documented instructions. Configuration choices made in the SCREENish dashboards — including whether screenshots are captured, the blur mode, and the monitor capture scope — are instructions given by the Customer.

3.3 SCREENish shall immediately inform the Customer if, in its opinion, an instruction infringes Data Protection Law. SCREENish may suspend the affected processing until the instruction is withdrawn, amended or confirmed.

3.4 SCREENish shall not process Customer Personal Data for its own purposes, and in particular shall not use it to train machine-learning models, to build benchmarks, profiles or datasets, to develop or improve products, or for any other purpose of its own, whether or not aggregated or de-identified, and shall not sell, rent or otherwise make it available to any third party except as permitted by clause 6. Processing that is necessary to provide, secure, support, back up, bill for and operate the Services — including administrative reporting on service configuration and operational health, used to run, support and safely change the Services — is processing on the Customer's instructions, not processing for SCREENish's own purposes. Operational reporting does not permit SCREENish to use captured content for cross-customer analytics, model training, profiling, benchmarking, dataset creation or product development, and never aggregates captured content: screenshot images, application names, window titles and notes are not included in any cross-customer statistic. This clause governs, and is mirrored by, Terms §9.5.

3.5 Evidence stays in the platform. SCREENish operates no export, download, webhook, integration or application programming interface that transmits screenshot images, application names, window titles, or biometric data out of the Services. Screenshot images are never served from SCREENish's own servers; they are delivered only as time-limited presigned storage URLs issued after a per-object authorisation check against the requesting session. Any alerting or integration feature that SCREENish may introduce shall carry verdicts, identifiers and aggregate figures only, and shall not carry the categories named in this clause.

3.6 Clause 3.5 does not restrict the Customer's own access to its data. The Services provide the Customer's authorised users with timesheet and work-log exports in spreadsheet, CSV and printable form, and these include the free-text notes field. Where the Customer subscribes to automated weekly or monthly reports, SCREENish sends those exports by email to the address the Customer configures. Those transmissions are made on the Customer's instruction; Annex IV records the Customer's responsibility for them, including for the security of the destination mailbox, which is outside SCREENish's control. Where the Customer creates an application programming interface key, registers a webhook address, subscribes to a feed address or connects a third-party tool, the data transmitted through that key, address or connection is limited to the categories clause 3.5 permits and is transmitted on the Customer's instruction to a recipient of the Customer's choosing. Annex IV records the Customer's responsibility for those recipients, for the secrecy of the key or address, and for revoking it when it is no longer needed.

4. Confidentiality

4.1 SCREENish shall ensure that persons authorised to process Customer Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

4.2 SCREENish shall ensure that access to Customer Personal Data is limited to personnel who require access in order to perform the Agreement. Support access to a Customer's or an employee's account through the operator session described in Annex II ("Support access") is limited to a single expressly authorised role, is used only to the extent necessary to provide support requested by the Customer or to resolve a fault affecting the Customer and within the Customer's instructions, and every use is recorded with its reason and notified as Annex II describes.

4.3 These obligations survive termination of the Agreement.

5. Security

5.1 Taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as well as the risk to data subjects, SCREENish shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as required by Article 32 GDPR.

5.2 The measures in force are described in Annex II.

5.3 SCREENish may update the measures in Annex II from time to time provided that the updated measures do not materially reduce the overall level of security.

5.4 The Customer is responsible for the security of its own systems, credentials and user accounts, including the administration of user access within its own organisation.

6. Sub-processors

6.1 The Customer gives SCREENish general written authorisation to engage Sub-processors, subject to this clause 6.

6.2 The Sub-processors engaged at the date of this DPA are listed in Annex III, together with the processing each performs, its location, and the transfer mechanism relied on where relevant.

6.3 SCREENish shall give the Customer at least 30 days' prior notice of the addition or replacement of a Sub-processor, by updating Annex III at the published DPA address and notifying the Customer by email to the address on the Customer's account.

6.4 The Customer may object to a proposed Sub-processor on reasonable data-protection grounds by written notice within that 30-day period. The parties shall discuss the objection in good faith. If it cannot be resolved, the Customer may terminate the affected Services on written notice, with a pro-rata refund of prepaid fees for the unused period, as its sole remedy.

6.5 SCREENish shall impose on each Sub-processor, by written contract, data protection obligations no less protective than those in this DPA, and shall remain fully liable to the Customer for the performance of each Sub-processor's obligations.

7. Data subject rights

7.1 Taking into account the nature of the processing, SCREENish shall assist the Customer by appropriate technical and organisational measures, insofar as this is possible, in fulfilling the Customer's obligation to respond to requests to exercise data subject rights under Chapter III GDPR.

7.2 The Services provide the Customer with the ability to access, correct, export and delete Customer Personal Data directly. The Customer shall use those facilities where they are sufficient to answer a request.

7.3 If SCREENish receives a request directly from a data subject relating to Customer Personal Data, it shall not respond to the substance of the request but shall forward it to the Customer without undue delay, and shall direct the data subject to the Customer.

7.4 Assistance beyond the facilities described in clause 7.2 and the forwarding in clause 7.3 is provided at the Customer's reasonable cost.

8. Assistance with Articles 32 to 36

8.1 Taking into account the nature of processing and the information available to it, SCREENish shall assist the Customer in ensuring compliance with the obligations in Articles 32 to 36 GDPR — security of processing, breach notification and communication, data protection impact assessments, and prior consultation with a supervisory authority.

8.2 The data protection impact assessment for the Customer's deployment is conducted and maintained by the Customer as controller; SCREENish cannot perform it on the Customer's behalf. SCREENish shall provide the technical and organisational information reasonably necessary for the Customer to conduct and maintain that assessment — including the description of functionalities, the categories of data processed, retention periods, recipients and Sub-processors, security measures, international transfers and automated functionalities set out in Annexes I to IV — together with the assurance materials referred to in clause 11.2 and reasonable further assistance under clause 8.1. Given the nature and combination of the workforce-monitoring functionalities described in Annexes I to IV, the Customer should treat a DPIA as a required pre-deployment compliance measure for the relevant deployment. The Customer remains responsible for determining and documenting the deployment-specific purposes, lawful bases, necessity and proportionality, risks to the rights and freedoms of data subjects, applicable safeguards and residual risk.

9. Personal data breach

9.1 SCREENish shall notify the Customer without undue delay and, where reasonably practicable, within 48 hours after becoming aware of a personal data breach affecting Customer Personal Data.

9.2 The notification shall describe, to the extent known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. Where the information cannot all be provided at once, it shall be provided in phases without undue delay.

9.3 SCREENish shall take reasonable steps to contain and remediate the breach and shall assist the Customer with its own obligations under Articles 33 and 34 GDPR.

9.4 SCREENish shall not notify a supervisory authority or any data subject about a breach affecting Customer Personal Data on the Customer's behalf, unless the Customer instructs it to do so in writing, or SCREENish is required to do so by law.

9.5 A notification under this clause is not, and shall not be construed as, an admission of fault or liability.

10. Deletion and return

10.1 At the Customer's choice, SCREENish shall delete or return all Customer Personal Data on termination or expiry of the Agreement, and delete existing copies, unless Union or Member State law requires storage.

10.2 The Customer may export its data through the Services at any time during the term. Following termination, SCREENish shall retain Customer Personal Data for 30 days to allow the Customer to export it, after which it shall be deleted. The Customer may request deletion earlier by written notice.

10.3 Deletion under this clause is subject to the retention periods in Annex I, which apply during the term as well. In particular, captured images — screenshots, photographs taken with the mobile application, and face-verification composites — expire automatically 45 days after capture and cannot be recovered after that point, including by SCREENish. The database records describing them are governed separately and, in some cases, are not time-limited at all; Annex I.E sets out which is which, and the Customer should not read a period stated for an image as covering the record of it.

10.4 SCREENish shall confirm deletion in writing on request.

10.5 Where Customer Personal Data remains in routine backups after deletion, SCREENish shall isolate it from further processing and delete it in accordance with its backup cycle.

11. Audits and inspections

11.1 SCREENish shall make available to the Customer all information necessary to demonstrate compliance with Article 28 GDPR, and shall allow for and contribute to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer, on the terms set out in this clause.

11.1a Sequence. Audits proceed in stages, each stage being used only where the previous one does not objectively satisfy the purpose of the verification: information and documentation under Tier 1 first; then third-party assurance materials; then, where clause 11.4 is met, a targeted remote audit; and an on-site inspection only where it is reasonably necessary to demonstrate compliance and cannot be satisfied by equivalent evidence, including a report under clause 11.6. These stages are organisational rules for the proportionate exercise of the audit right; they do not exclude it.

Tier 1 — information, always available

11.2 On written request, and without further condition, SCREENish shall provide:

(a) the description of technical and organisational measures in Annex II;

(b) a completed security questionnaire, once per twelve months;

(c) the third-party assurance materials SCREENish holds in respect of its Sub-processors, including SOC 2 and ISO certifications and transfer impact assessments, to the extent SCREENish is permitted to share them; and

(d) written answers to the Customer's specific questions about the processing.

11.3 The parties agree that Tier 1 will satisfy the Customer's obligations in the ordinary case.

Tier 2 — inspection

11.4 The Customer may conduct an on-site or remote inspection only where at least one of the following applies:

(a) the information provided under Tier 1 is demonstrably insufficient to resolve a specific compliance concern the Customer has raised in writing, and SCREENish has failed to resolve that concern within 30 days of the written notice;

(b) a personal data breach affecting the Customer's Personal Data has occurred; or

(c) a competent supervisory authority requires the inspection of the Customer.

11.5 Any inspection under clause 11.4 is subject to all of the following:

11.6 Substitution. SCREENish may satisfy any request under clause 11.4 by commissioning, at its own election and expense, an audit by an independent third-party auditor and providing the resulting report to the Customer.

12. International transfers

12.1 SCREENish shall not transfer Customer Personal Data outside the European Economic Area except in accordance with Chapter V GDPR.

12.2 Annex III identifies, for each Sub-processor located outside the EEA, the transfer mechanism relied on.

12.3 Where the Standard Contractual Clauses apply to a transfer under this DPA, Module Three (processor to processor) shall apply where SCREENish acts as processor and the recipient as sub-processor, and Module Two where SCREENish acts as controller. The module applicable to each transfer is identified per transfer in Annex III, on the basis of the actual roles of the parties to that transfer. The Annexes to this DPA populate the corresponding Annexes to the SCCs, and clause 11 of this DPA governs audits under Clause 8.9 of the SCCs.

12.4 The competent supervisory authority for SCREENish is the Commission for Personal Data Protection of the Republic of Bulgaria (Комисия за защита на личните данни), 2 Prof. Tsvetan Lazarov Blvd, Sofia 1592, Bulgaria.

13. Liability

13.1 SCREENish's total aggregate liability to the Customer arising out of or in connection with this DPA shall not exceed the fees actually paid or payable by the Customer under the Agreement during the twelve (12) months immediately preceding the event giving rise to the claim. This cap and the cap in Section 22 of the Terms are one and the same aggregate amount, calculated once across the Agreement and this DPA; they are not two separate caps.

13.2 The cap in clause 13.1 does not apply to liability arising from intentional (wilful) misconduct or gross negligence, or to the extent that its application would unlawfully restrict the rights of data subjects or exclude or limit liability that cannot lawfully be excluded or limited under applicable Data Protection Law, the applicable Standard Contractual Clauses, or other mandatory law.

13.3 This clause governs contractual claims between the parties. It does not govern, and does not limit, the claims and rights of data subjects, which are exercised under applicable law and, where applicable, the SCCs; clause 15.3 applies.

14. Term, variation and precedence

14.1 This DPA takes effect as set out in the preamble and continues for as long as SCREENish processes Customer Personal Data on the Customer's behalf.

14.2 Published version. The current version of this DPA is published at https://www.screenish.com/dpa and is incorporated by reference into the Agreement. SCREENish may update it to reflect changes in law, in the Services, or in its Sub-processors, on 30 days' notice; clause 6.4 governs objections to Sub-processor changes specifically.

14.3 Signature on request. SCREENish shall, at the Customer's request, execute a counterpart of this DPA in the same terms.

14.4 Negotiated variations. Except for updates to the published DPA made in accordance with clause 14.2, no Customer-specific amendment, variation or rider to this DPA is effective unless agreed in writing by the parties.

14.5 Precedence. Where the parties have executed a written rider varying this DPA, that rider prevails over this published baseline for that Customer alone, to the extent of the inconsistency, and does not affect the baseline as it applies to any other customer. Subject to that, in the event of a conflict between this DPA and the Agreement, this DPA prevails in relation to the processing of Customer Personal Data.

15. Governing law and jurisdiction

15.1 This DPA is governed by the law of the Republic of Bulgaria, without regard to its conflict-of-laws rules.

15.2 The courts of the Republic of Bulgaria have exclusive jurisdiction over any dispute arising out of or in connection with this DPA, subject to clauses 15.3 and 15.4.

15.3 Data subjects' rights are unaffected. Nothing in clause 15.2 limits the right of a data subject to bring proceedings before the courts of the Member State in which they are habitually resident, whether under Article 79 GDPR or under the Standard Contractual Clauses. That right cannot be excluded by agreement between the parties, and this DPA does not attempt to.

15.4 Where the Standard Contractual Clauses apply, their own governing-law and forum provisions govern those Clauses. This clause is drafted to sit consistently with them: Bulgarian law is the law of an EU Member State that allows for third-party beneficiary rights, which those Clauses require.

15.5 Precedence over the Agreement's dispute-resolution terms. Where the Agreement provides for a different forum or procedure, this clause prevails in relation to the processing of Customer Personal Data, in accordance with clause 14.5.

Annex I — Description of the processing

I.A Subject matter, nature and purpose

Continuous workforce time-tracking and activity monitoring of the Customer's personnel, for the purpose of recording working time and activity, for the duration of the Customer's subscription. Processing is automated and continuous while an individual runs the tracking application.

I.B Categories of data subjects

The Customer's personnel (employees, contractors and freelancers) enrolled in the Services; the Customer's own administrative users; and any third party whose personal data appears incidentally in captured content (see I.D).

I.C Categories of personal data

The rows above reflect the full-code inventories of 2026-07-31 and 2026-08-14.

I.D Special categories of data (Article 9)

Both paths below are live, not theoretical, and neither is apparent from the product description.

1. Health data. At least one Customer's staff handle medical records, so health data reaches the platform. It is not confined to screenshot images: it is captured verbatim as indexed, searchable plain text in window title — patient name, treating provider and clinical specialty can appear together in a single field. This matters because that column has a different and shorter-lived protection than the images: it is purged by an application job at 93 days, not by the storage layer, and unlike an image it is queryable and exportable. The same pattern occurs at smaller scale in the note field of the screenshot record. The Customer is responsible for determining whether, and under what legal conditions, its monitoring configuration may capture special-category data; SCREENish processes any such data only as necessary to provide the Services and on the Customer's documented instructions, does not search for, extract, classify or infer from it, does not use it for any secondary purpose or model training, and applies to it the same security, access, retention and deletion controls as to the surrounding data. Whether SCREENish creates derived data was checked in the same inventory: the platform computes activity-level baselines and grades from counters and timestamps only; no health-related classification, inference or score is produced from captured content.

2. Facial images and biometric processing. Two distinct artefacts are processed by the Services and should not be treated as identical:

• The enrolment photograph (the storage key of the facial reference photograph). The employee submits the photograph and the employer approves it. Verified against the code: SCREENish's servers never transmit this photograph to the tracking application — the application's configuration payload carries only whether face verification is enabled, whether a photograph has been requested, and the minimum acceptance rate. The only verified readers are the employer approval screen, the administrator interface, and the employee's own profile, each served through a short-lived presigned URL. Its function is visual confirmation by a human that the profile in the application was created in the likeness of the person hired.
• Verification composites and scores (the face-verification result records: the storage key of the review composite, average match rate, period count, camera-obstruction flags). Verified against the tracking application's own source (read 2026-08-10): the biometric comparison runs on the employee's device — the face-recognition models ship inside the application and the embedding comparison executes locally. A verification cycle that succeeds persists no photograph at all. A failed or aborted cycle stores the frame encrypted on the device (AES-GCM under a machine-bound key), and a composite of up to six such failed frames is uploaded to the Customer's account for human review, after which the local files are deleted. The composite is stored under the 45-day lifecycle prefix; the score row follows the one-year record rule. Since August 2026 the report row also carries an anti-spoof layer, produced on the employee's device and ingested by the server (verified in the server ingest code, 2026-08-14): the application flags a suspected presentation attack — a photograph or video replayed at the webcam (spoof suspected with cycle counters, first/last-seen timestamps and spoof details) — and, separately, a loop replay in which the face check passes but the frames repeat at a fixed period (frame recurrence suspected, recurrence score, recurrence period, recurrence details), alongside a neutral camera-device classification (camera-device classification, e.g. a virtual-camera token). These are suspicion markers about the individual's conduct, not measurements of the face; every column defaults to zero or null and populates only when a tracking application that ships the detectors reports it. An hourly job raises new markers to the employer and current administrators by bell and email, with a six-hour cooldown per incident; their visibility is one-way — see I.F.

No facial-recognition SDK or third-party biometric service exists anywhere in the server-side platform, and the only storage recipient of these images is AWS S3.

Lawfulness of enabling the feature rests with the Customer. Whether or not these artefacts are classified as special category data, the Customer, as controller, is responsible for determining whether face verification may lawfully be enabled for particular personnel, and for establishing — where the GDPR applies — a valid Article 6 basis and an applicable Article 9(2) condition, or — where it does not — the equivalent basis, notice, consent or authorisation required by the law applicable to the monitored individual. Laws governing biometric and workplace-monitoring technologies differ materially between jurisdictions; SCREENish provides the technology and does not determine, and cannot warrant, the lawfulness of any particular deployment.

Legal classification. The legal classification of each category of face-verification data depends on the nature of the data and the specific technical processing performed on it, assessed artefact by artefact — not on the location of the processing alone. Where the processing of an artefact constitutes processing of biometric data within the meaning of Article 4(14) GDPR and falls within Article 9 GDPR, the applicable requirements of Article 9 apply to it. That assessment has been performed artefact by artefact with counsel, and the treatment of each artefact in this Annex reflects it.

I.E Retention

Images and database rows are governed separately, and the distinction is the whole of this section. Images expire at the storage layer on a fixed clock. The rows that describe them — which carry location coordinates, free-text notes and behavioural scores — are governed by an application job, or in some cases by nothing at all. A period stated for a photograph does not cover the record of it.

Images, deleted by the storage layer

The bucket carries one expiry rule (configuration captured 2026-08-02):

Two further rules exempt two placeholder error images for ~275 years; they hold no personal data. Bucket versioning has never been enabled, so expiry is a real deletion rather than a delete marker over a surviving version.

The rule is scoped to the monitoring-data area as a whole, so it reaches every customer folder beneath it. It does not reach the facial-reference area, the profile-photograph area, the public artwork area, or the bucket root.

Enforced in fact, not merely configured: on 2026-08-02 the oldest surviving object under the monitoring-data area was 46 days old against a 45-day rule — S3 rounds to UTC midnight and deletes asynchronously. For contrast, the oldest object under the facial-reference area was 278 days and under the profile-photograph area 3,715 days.

Database rows, deleted by a nightly job

GPS coordinates are a column on the screenshot row, not a separate object. They therefore follow the 365-day row period and are not affected by the 45-day image rule.

The behavioural-detection state tables run on a different clock deliberately. They are current state, not history: the baseline histogram is recomputed nightly while its user generates screenshots, and the dismissal counter grows only when the Customer's reviewer dismisses a flag — so a clock on creation would delete live rows. The clock is on last update: a row untouched for a year belongs to someone gone for a year. They are equally deliberately not deleted on deactivation, because deactivation is frequently temporary, and a returning worker keeps both their baseline and — more importantly for the data subject — the dismissal counters that suppress repeat false alarms about them.

Data with no retention rule at all

None remains. This table listed three entries when first drafted; each acquired a rule and moved into the schedule above — phone-photograph rows at 45 days with the photographs they describe (2026-08-02), face-verification result rows at one year (2026-08-10), and the behavioural-detection state tables at one year from last update (2026-08-10). The one deliberate exception to clock-based deletion is the facial reference photograph, below, which is event-based by design.

Facial reference photographs

Deleted on an event rather than on a clock, and deliberately so: on withdrawal of face-verification consent, on replacement by a new upload, and on deactivation of the employment. While an employment continues the reference is retained, because staff commonly stop and resume work and would otherwise have to enrol again each time. The the facial-reference area prefix is outside the lifecycle rule, so there is no time limit behind those events. The database row is marked deleted rather than removed.

Profile photographs (avatars)

Event-based, like the facial reference: the previous object is deleted when a new photograph is uploaded. While a profile is in use its photograph is retained, because it is displayed to the team. Objects that predated the bucket's default encryption were re-encrypted in place on 5 September 2026 (census the same day: 346 of 346 encrypted).

Operational logs, audit records and backups

Points that must not be softened

• Screenshot rows are purged relative to a client-supplied timestamp that is never validated server-side. The highest value present is 2038-01-18, which defers that row's purge by twelve years.
• The nightly job's deletions of the review and tombstone tables are best-effort: a failure is silent and unlogged.
• Images expire long before their rows, so a screenshot row between 45 days and one year old carries no image — and a face-verification result row between 45 days and one year old points at nothing.

I.F Visibility of automated assessments — one-way by design

Every output of the automated assessment layer is visible to the Customer's reviewing side and none of it to the monitored individual. The activity-pattern grades and review windows of I.C surface to the employer and current administrators through the review queue, a bell notification and an optional daily email digest. The camera-spoof and replay markers of I.D surface through the employer's worklog view and an hourly alert email to the same recipients; that email itself instructs them to keep the suspicion manager-only while they verify. High-grade activity findings and each camera alert are additionally copied to SCREENish staff for operational triage, as verdicts and identifiers only, consistent with clause 3.5.

The monitored individual is shown none of this, and the concealment is enforced in code rather than left to configuration: the employee's own dashboard endpoint deletes the suspicion fields from the response and withholds the face-verification composite of any spoof-touched report before the response leaves the server (verified against the source, 2026-08-14). A Customer wishing to inform or confront the individual must therefore do so outside the product. The dismissal counters that suppress repeat false alarms (I.E) are equally invisible to the individual they protect. One further detector — the remote-desktop (faked-input context) probe — currently runs in shadow mode: its would-be decisions are written to a server-side log that only SCREENish reads, so today neither the individual nor the Customer sees them.

Annex II — Technical and organisational measures

Encryption in transit. The Services are served over HTTPS with TLS 1.2 and TLS 1.3 only. Plain HTTP and the apex domain are permanently redirected. Responses carry HTTP Strict Transport Security with a two-year max-age, covering all subdomains.

Encryption at rest. Objects written since approximately October 2022 are encrypted at rest with server-side encryption (SSE-S3 / AES-256). Default encryption is not retroactive and no re-encryption has been performed, so objects written before that date are not encrypted. Stated precisely, because the difference matters by category:

• All monitoring data is encrypted. Everything under the the monitoring-data area prefix — screenshots, thumbnails, phone photographs, face-verification composites — is encrypted, and remains so permanently, because the 45-day expiry means nothing there predates the cutover. Facial reference photographs under the facial-reference area are encrypted in full: 103 of 103 objects, verified by census.
• Profile photographs under the profile-photograph area are encrypted in full: the objects that predated the bucket default were re-encrypted in place on 5 September 2026 (census the same day: 346 of 346).
• One older category is not. Approximately 1,130 database backups written before October 2022 are unencrypted at rest. Every one of them is older than the one-year retention in Annex I.E and is being expired by the retention job, which removes up to 30 of them per night; none will remain once that backlog is drained.

The application does not set encryption parameters on upload and performs no client-side encryption; encryption comes from the bucket's default setting.

Object delivery. Screenshots, their thumbnails, photographs taken with the mobile application, and face-verification artefacts are never served from SCREENish's own servers, and are not publicly readable. The browser obtains a short-lived presigned storage URL from a server-side authorisation endpoint that validates the caller's access to that specific object first; worklog thumbnails are resolved the same way, in batches, before the image is requested. Presigned URLs expire after 60 minutes for screenshots and thumbnails and after 10 minutes for face-profile review.

Two prefixes are readable without authentication, and are named rather than glossed: the public artwork area (marketing and blog artwork, no personal data) and the profile-photograph area (profile photographs). For the profile-photograph area the exposure is bounded by construction: the prefix cannot be listed (an anonymous listing request is refused — verified 4 September 2026), and each object key carries the account identifier and the upload time to the second, so a photograph is reachable only by someone to whom its exact address has been shown — the members of the team to whom the profile photograph is displayed. Objects are encrypted at rest, and the previous photograph is deleted when a new one is uploaded (Annex I.E).

Support access (operator session). A single support role, held by one named person, can open a session in a Customer's or an employee's account through SCREENish's internal administration console without the account's password or second factor, in order to see exactly what that user sees. It is used only to the extent necessary to provide support requested by the Customer or to resolve a fault affecting the Customer, and within the Customer's instructions. A reason is mandatory — the session is refused without one — and every use writes an audit record (the security audit log) with the operator, the account opened, the time, the originating address and that reason, and immediately sends two notifications: one to SCREENish's owner, so that a session the owner did not cause is visible the moment it happens, and one to the holder of the account that was opened, stating when and why. The audit records are retained as Annex I.E describes.

Diagnostic records. When a fault needs to be investigated, the tracking application can upload its own log files from the employee's device. It does so only where the Customer has enabled diagnostic collection for that assignment — a per-assignment setting, off by default, every change of which is journaled like the other capture settings — and only while a request for that employee is open in SCREENish's request register (the diagnostic-request register: who requested it, when, why, until when). The archive contains no screenshots and no images: it holds the user identifier and work e-mail, the names of applications, windows and files that were open, device and operating-system information, error messages and the application's own measurements. The application keeps at most ten days of logs, so an archive never covers more; after an upload the application shows the employee that a record was sent, when, and what period it covered. Archives are stored under the employee's own the monitoring-data area folder and expire with the 45-day storage rule; access is limited to the support role; the request register is the audit trail.

API access and outbound connections. Where API access is offered, application programming interface keys are stored only as a one-way hash, are shown in full once at creation, are bound to a single customer account, can be revoked instantly by the Customer and by SCREENish, are rate limited, and every use is logged with time and origin. Outbound webhook requests are signed with a per-address secret so the recipient can verify their origin, are sent only to https addresses, and each delivery attempt and its result is recorded. Feed addresses carry a revocable token. None of these routes can return a screenshot, an application name, a window title or biometric data.

Scheduled jobs. Every scheduled endpoint requires a shared secret presented in a request header, compared with a timing-safe comparison; a request without it is refused with 403 and logged with the calling address. This covers the retention job, the reporting jobs and the sitemap generator.

Ingest. The screenshot ingest endpoint receives metadata only — file name, timestamps, activity counters, notes and the program list. The image itself is uploaded by the tracking application directly to object storage under short-lived STS credentials scoped to that employee's own folder, so SCREENish's web tier never handles the image bytes.

CSRF. State-changing requests to the employer, delegated-administrator and employee JSON APIs carry an anti-forgery token in a dedicated request header, compared against the session token with a timing-safe comparison. A missing or mismatched token is blocked — the request is rejected and execution stops. Blocked attempts are additionally written to a log, and a scheduled job emails a digest of them; the logging supplements the block, it does not replace it.

Authentication. Users may optionally enable TOTP two-factor authentication with backup codes and trusted devices. Where it is enabled, the second factor is enforced at the API layer: a session that has passed the password but not the second factor is refused by the employer, delegated-administrator and employee interfaces alike, and cannot disable two-factor authentication, regenerate backup codes or register a trusted device. It remains opt-in per user — a Customer cannot currently mandate it for its staff.

Role separation. Four session types exist — employer, employee, delegated administrator, and project-share recipient — each served a different dashboard. The employer API rejects employee sessions and the employee API rejects employer sessions.

Project-share scoping. Where the Customer issues a project share link, the resulting session is bound server-side to that one project: worklog records, the employee list and image authorisation are all filtered by a project identifier held in the session and never taken from the client. Access requires the link together with a passcode.

Consent records. Consent for face verification is recorded in a versioned, auditable structure with an immutable audit trail (the consent status records, the consent audit trail, the consent-request records). The runtime flag that instructs the tracking application to perform face verification requires both the employment-level setting and a recorded grant — a product control that applies regardless of the Customer's choice of legal basis. Where the Customer relies on the employee's explicit consent as the applicable condition under Article 9(2)(a) GDPR, the recorded grant functions as the record of that explicit consent; the record itself does not establish the Customer's legal basis under Article 6 GDPR or a condition under Article 9(2) GDPR.

Terms acceptance. Terms are maintained as numbered versions, and acceptance is recorded per version with timestamp, IP address, user-agent and acceptance method.

Capture minimisation available to the Customer. Screenshot capture can be switched off entirely per assignment. Capture covers a single display by default and can be extended to all connected displays — a standalone scope setting, independent of the blur setting — in which case the displays are captured together and merged into one composite image that is then treated as the screenshot. Separately, a blur mode (whole-screen or selective) can be selected; whichever the capture scope, the selected blur mode is applied to the resulting frame in exactly the same way. See Annex IV for the limits of what selecting blur guarantees.

How whole-screen blur works (verified in the application source, 2026-08-14): the frame is destructively downscaled by area-averaging to a small fraction of its resolution, lightly smoothed, and scaled back up — a "frosted glass" image in which text is unreadable while layout, colours and coarse activity remain visible. Because the reduction happens on the device before upload, the discarded detail is not recoverable from the uploaded image. No text recognition or content reading of any kind is involved, and the mode behaves identically on every platform. The same transform serves as the universal fallback of the selective mode below.

How selective ("smart") blur works (verified in the application source, 2026-08-14): before upload, the chosen screenshot is read in its entirety, on the device, in memory. An OCR pass covers the whole frame — a native-resolution pass plus a contrast-enhanced, upscaled pass, combined so that small and low-contrast text is read too — using the operating system's own OCR engine on Windows and a neural OCR engine bundled with the application on macOS and Linux. No network service is involved at any step. The recognised text is then checked by deterministic detectors with validity checks (payment cards by Luhn, IBANs by checksum, phone numbers by number validation; identity numbers, e-mail and IP addresses, account numbers, credential patterns and private-key markers), and by a local ML model for personal names and addresses that is loaded for the frame and unloaded after it. The matching regions are blurred and the image ships. Everything the pass reads — text, coordinates, detections — exists only in the application's memory for that one frame: nothing recognised is stored or transmitted, and the local log receives only counts and timings (e.g. a word count). The mechanism is strictly subtractive: its only output is the same screenshot with more of it obscured.

Every failure mode ships more blur, never less. An OCR or model error, expiry of the two-minute processing budget on a slow machine, a screen too dense to redact reliably (over 3,000 recognised words — where a missed name would otherwise slip through), a screen that looks like a credential or configuration file, and low free memory each cause the frame to ship whole-frame blurred. An all-display composite passes through this same pipeline — carrying more text, it merely reaches the density cap sooner, with the same whole-frame outcome. The Annex IV caveat stands: SCREENish cannot verify that a given client build applied any of this.

Annex III — Sub-processors and recipients

III.A Sub-processors

Cloudflare does not front the main application. www.screenish.com resolves directly to the origin server; Cloudflare therefore does not see dashboard traffic, logins or authorisation requests. It does receive the recipient's IP address and user-agent when a transactional email is opened, because every email template embeds an image hosted on the images. subdomain.

III.B Other recipients

These receive personal data but are not sub-processors of Customer monitoring data. They are disclosed because an Article 28(2) authorisation chain is only as good as its completeness.

inv.bg is not a recipient by the route previously assumed: the local invoicing table is a staging copy in SCREENish's own database, and writing to it transmits nothing. inv.bg does receive invoicing data through separate authenticated API calls that return invoice documents. inv.bg (Invoicing Solutions Bulgaria AD) processes those details — company or individual name, contact person, address — as a processor under section 4 of its terms of service, on servers in Bulgaria and Germany, with no transfer outside the EEA and no sub-processor outside the EEA (confirmed in writing, 31 July 2026).

MailChimp receives no personal data and is not a sub-processor. No MailChimp code path or credential remains in the platform.

Annex IV — Customer responsibilities

The following are the Customer's decisions and obligations as controller. SCREENish neither makes nor reviews them.

1. Lawful basis and transparency. Determining whether its use of monitoring features — screenshots, activity capture, location tracking, face verification and the rest — is permitted under the laws applicable to the Customer and to the individuals monitored, which are frequently not the same jurisdiction; establishing a lawful basis for that monitoring; obtaining any notices, consents or authorisations applicable law requires; completing any data protection impact assessment; and giving monitored individuals the notice the law requires. Given the nature of continuous workforce monitoring, a DPIA should be assumed to be required.

2. Capture configuration as documented instructions. Per employee-project assignment the Customer configures: screenshots on or off; capture scope (single monitor or all monitors); blur mode (off, whole screen, or selective); program and window-title reporting on or off; and idle-time reporting. Face-verification settings are configured on the employment record; as a product control, the tracking application activates face verification only where a recorded grant is present for the employee. Where the Customer relies on the employee's explicit consent as the applicable condition under Article 9(2)(a) GDPR, that record functions as the record of explicit consent; in every deployment the Customer, as controller, remains responsible for determining whether face verification may lawfully be used for the individuals concerned and for establishing the applicable legal basis under Article 6 GDPR and a condition permitting the processing of biometric data under Article 9(2) GDPR. Each of these is an instruction under clause 3.2.

3. The limits of blur. Blur is a data-minimisation feature available to the Customer, not a guarantee: its effectiveness depends on the applicable client application version, configuration and proper operation, and it must not be relied upon as the sole safeguard against the capture or disclosure of sensitive information. Blur is applied by the tracking application on the employee's own device. SCREENish transmits the selected mode to the application and never receives the unblurred image, but it cannot verify that any given client applied it: there is no server-side record of the mode actually applied to a given screenshot, and older application builds continue to upload unblurred images. Selecting a blur mode does not guarantee blurred output across a fleet, and the Customer must not rely on it as a technical control against a specific disclosure risk. Older client generations that can no longer be updated on some machines do not carry all of the measures described in Annex II — they have no blur at all — and the dashboard warns the Customer when it enables a setting that the client installed on an employee's machine cannot apply. (Built since 3 September 2026: every change to a capture setting is journaled with who changed it and when, and every frame from a current client carries the client version, so the mode issued for any given capture is derivable — a frame from a legacy client carries no version stamp and was not blurred. Still pending, and this paragraph will not be softened before it ships: a lifecycle policy for outdated client builds — warning, forced update, then refusal.)

4. Contents of free-text fields. Project titles and descriptions, notes, automated-report names, and distraction-rule entries are authored by the Customer and its personnel. SCREENish applies no semantic restriction to them and does not review their contents. Where those fields or captured window titles contain special-category data, that is a consequence of the Customer's own working practices.

5. Exports and emailed reports. Work-log and timesheet exports available to the Customer's users include the notes field. Where the Customer subscribes to automated weekly or monthly reports, those exports are emailed to an address the Customer configures, leaving SCREENish's systems. Securing that mailbox, and deciding whether to enable those reports at all, is the Customer's responsibility.

6. API keys, webhooks, feeds and connected tools. Where the Customer creates an application programming interface key, registers a webhook address, subscribes to a calendar or spreadsheet feed address, or connects a third-party tool such as a messaging or project-management service, SCREENish transmits work-time, activity, membership and assessment data, and never the categories named in clause 3.5, to the destination the Customer configured. The destination service is the Customer's own recipient and, where it processes personal data on the Customer's behalf, the Customer's own processor; it is not a Sub-processor of SCREENish. Choosing that recipient, satisfying itself as to its security and its terms, informing monitored individuals about it where the law so requires, keeping keys and addresses secret, and revoking them when they are no longer needed, is the Customer's responsibility. Every key, address and connection is created by an authorised user of the Customer after accepting the API access terms, and that acceptance, the creation, each use and the revocation are recorded.

7. User administration. Managing who within the Customer's organisation holds employer, administrator and project-share access, and revoking it when it is no longer needed. Note that a delegated administrator currently operates with the full access of the employer account; the Customer should treat delegated-administrator access as equivalent to account owner access until that changes.

8. Third-party personal data. Where the Customer stores its own clients' personal data in the Services, it remains the controller of that data.

9. Transparency about automated assessment. The Services may generate automated activity assessments and integrity indicators and make them available to the Customer's authorised reviewing users as described in Annex I.F. SCREENish provides a standard in-product disclosure informing monitored individuals of the existence and general nature of this processing. The Customer, as controller, remains responsible for providing all information required by Articles 13 and 14 GDPR for its particular deployment, including the purposes, applicable legal basis, recipients and employment-related use of the information. The Customer is also responsible for determining whether and when an individual finding should be communicated in connection with an employment or disciplinary process. Nothing in this allocation limits the data subject's right of access or SCREENish's obligation to assist the Customer under clause 7.