OpalSpan: data processing agreement
Version and particulars/annex version: dpa-en-2026-10-19-v9. Instructions version: dpa-instructions-en-2026-10-19-v9.
Parties and applicability
Processor: Ready IT ApS, CVR 38769383, c/o Matt Luccas Phaure Jensen, Viften 18, 1. 1, 2670 Greve, Denmark; contact@readyit.dk.
Customer: the contracting customer identified in the accepted OpalSpan order, with the address and authorised contact recorded for that customer. The order and its recorded electronic acceptance identify the effective agreement date and agreement reference.
This agreement applies where Ready IT processes personal data on the customer's behalf in providing the instructed OpalSpan technical-work service. The customer is controller for data whose purposes and means it determines. Where the customer is itself a processor, Ready IT acts as an authorised subprocessor; the customer's relevant controller instructions and authority apply. References below to controller instructions include that authorised chain.
Buying as a business or a consumer does not by itself decide that data-protection role. Purely personal/household use and Ready IT's own account, security and billing purposes do not become controller-to-processor processing merely because this agreement accompanies the subscription.
Processing particulars and instructions
Subject matter and purpose: hosting and organising the customer's authorised technical-work records and enabling remote technical access, customer/case coordination and, when instructed, hosted OpalSpan Mech assistance, including prospectively confirmed schedules/alerts and minimised monitoring of the exact instructed enrolled devices. This addition excludes Automation/critical mail.
Nature: receipt, recording, organisation, storage, authorised retrieval and use of customer/contact/company records, case notes and drafts, device links, selected diagnostic information, files, conversations and tool evidence; communication to the relevant enabled service providers for those functions; and return/deletion as instructed. Hosted Mech can use relevant records across cases within the authorised workspace. Separate chats are not a new confidentiality boundary.
Duration: while those processing services are provided and while completing the customer's return/deletion instructions, subject to lawful mandatory retention. Cancelling payment and continuing on Free does not end the data processing service or itself instruct deletion.
Data subjects: the customer's users/technicians, customers and their contacts, device users, and other people whose information is included in authorised case, file, diagnostic or conversation material.
Personal-data types: names and contact/business details; workspace and device identifiers; case communications and notes; selected device/account, system, software, network and diagnostic information; and personal data present in the particular authorised files, conversation context and tool results. This description is not an instruction to indiscriminately copy device contents, credentials or unrelated sensitive information. Specific additional categories and purposes must be covered by the customer's lawful instructions before inclusion.
The accepted service order, this annex, the versioned OpalSpan processing instructions and the customer's authorised workspace actions are the documented instructions. The customer determines the lawful basis and required notices for its controlled data and has the authority needed to supply it, grant technical access and issue these instructions. An upstream processor must remain within the relevant controller's instructions and permissions.
Particulars of cumulative Telemetry
Disabled, Light and Full are one Telemetry feature, including resource usage. Light contains fourteen closed IDs and legacy Full all thirty-two IDs enumerated in privacy-en-2026-10-19-v9 and dpa-instructions-en-2026-10-19-v9. Full includes every Light signal plus the existing bounded update/protection/service/battery/event/ hardware indicators, temperature and dedicated GPU-memory readings. Native unsupported and inapplicable fields remain explicit; a point reading or absent source is not a whole-device health or security assessment.
The original first-slice, catalogue and resource identities retain their exact historical meanings. An old agreement/profile binding is not the new combined scope. Device/boot/batch/volume/event linkage and these states can be personal data; anonymity or cross-device unlinkability is not promised.
Nature: bounded local source projection, authenticated receipt/validation, tenant-qualified recording/retrieval/pruning, deterministic alerts and necessary context for an independently authorised Mech run. No raw log/report/file body, EventData, threat/product/app/service/account name, inventory, serial, network identifier, path, command or environment data enters the background feed. Unknown profiles and unsupported/failed evidence do not become healthy results. No routine DiagnosticSnapshot or new provider/service is introduced.
The original holder/controller or authorised upstream processor must issue a prospective explicit instruction bound to exact full document versions/hash, named current targets/profile, actual purpose/capacity and protected attributed request evidence. That optional feature-only acceptance preserves original orders, prices, rights, credits/exemptions and accounting. It does not replace the first-slice instruction for other targets or grant access, user consent or an automatic profile upgrade. Each device additionally needs the required informed profile-specific user consent or evidenced necessity for monitoring that user expressly requested, native capability and explicit profile selection. Publication, continued use, silence, enrolment, a role, budget or earlier DPA supplies none of those facts. Ready IT retains its own duties where it determines purposes/means.
Historical readings expire seven days from observation; events/alerts thirty days from occurrence. Ingestion receipts expire thirty days and are count-bound. Latest non-event state and protected comparison/dedup/authority metadata remain separate while enrolled and can be stale. The unsent queue is at most64batches/ 256KiB, expires after seven-day original sample age during operation/next startup and clears on acknowledgement/off/downgrade. A stopped device is not remotely wiped. Transfer/retirement removes affected old-workspace latest and authority; return/deletion/recovery obligations and separate required evidence remain.
Monitoring/deterministic evaluation consumes no AI/device-work units or default model feed. Actually authorised Mech runs retain their existing frozen authority/ configuration/model/budgets/accounting and disclosed provider boundaries. Critical/Automation mail remains disabled; there is no new SES/Graph purpose, permission, recipient/body approval, price or financial wallet.
Resource usage and prospective enrolment preferences
Light includes aggregate CPU activity and the supported existing uptime/memory signals as well as the baseline indications. Full adds bounded reported sensor temperature and dedicated GPU-memory usage/capacity/utilization alongside the other supported telemetry. Exact per-OS sources and limits are in the v9 notice and instructions. Utilization is not reclaim pressure; sensor temperature is not necessarily CPU die temperature. macOS remains a technical preview with native source gaps stated honestly.
Both tiers retain five-minute cheap/fifteen-minute night sampling, hourly/daily slow-source cadence, six-hour keyframes,64signals/16KiB per batch,256KiB/day and 64queued batches/256KiB. Retention, providers, rights, pricing, original tariffs and separately authorised deeper-work scope are unchanged.
The workspace may record Full as a prospective default for new enrolments. That preference is not consent or technical-access authority for an unknown future device user. Collection on each device remains bound to current lawful instruction, attributed consent or evidenced necessity for the expressly requested service, supported advertised native capability and local opt-out. Changing the default alone does not broaden existing devices or rewrite old observations, contracts or authority records.
Logical-processor CPU scope
The explicitly selected richer Full profile (telemetry-full-v2) contains all
thirty-two legacy Full signal IDs plus cpu.logical_utilization_pct,
cpu.busiest_logical_utilization_pct, cpu.logical_count, cpu.measured_count
and cpu.interval_seconds. Old Light/Full grants and future-device defaults
retain their exact profiles; an upgrade or a read never expands collection.
Selection requires a new exact instruction and applicable attributed authority
bound to these v9 documents and the independent whole-pack hash. This profile
is not a new subscription, diagnostic report or higher sampling rate.
Each logical-processor reading is a 0–100 percentage with a collection/topology- scoped numeric OS index, source timestamp and interval start. A logical processor is not a physical core. A fresh collection epoch, topology change, invalid or zero interval, counter reset or failed read establishes a baseline or gap, not an invented zero. The busiest value identifies the maximum only when all expected logical processors have valid readings from the same interval; numeric processor group/index order resolves ties. Partial individual evidence remains available. Utilization alone is neither a diagnosis nor evidence of thermal throttling.
Windows uses public PDH Processor Information idle counters with group/index instances, including groups beyond 64 logical processors. Linux uses /proc/stat cpuN counters without counting guest time twice; idle and iowait are non-busy, steal remains non-idle, and decreasing iowait produces an unavailable interval. macOS uses host_processor_info CPU-load ticks and releases its allocated buffer; uint32 tick wrap is distinguished from invalid backwards counters. macOS remains a technical preview. Existing aggregate CPU semantics are unchanged, including Windows aggregate unavailability above 64 processors.
The richer profile accepts at most 256 logical-processor instances and 326 scalar signals/96 KiB per batch. Above that topology bound it reports the observed count and source_bound without claiming a partial list is complete. Collection failures are informational and do not gate independent access, execution or aggregate collection. The existing five-minute/day and fifteen-minute/night cadence and 64-batch/256 KiB protected spool remain. The explicitly negotiated richer profile has a 32 MiB/day transmission ceiling; legacy profiles retain 256 KiB/day. Large topologies can exhaust those byte bounds sooner; gaps and stale readings must remain visible. Existing storage and pruning are unchanged: seven-day historical numeric readings and thirty-day events, with existing row bounds potentially shortening history. No provider, time-series backend, unbounded history, driver, fan, thermal sensor or proprietary vendor integration is added.
Authenticated requested telemetry
An explicit telemetry request from the signed-in authorised technician is the service action and its attributed request evidence. Within the actual permitted workspace/device scope, the service fills the required purpose/capacity, published profile/document binding and current revisions and records the prospective instruction and requested-service necessity. Mech trusts that technician request and attempts the permitted command; it does not ask the person to prove their general authority, complete a personal questionnaire, find a separate consent package or approve the same requested telemetry again.
This service-owned evidence is not a fabricated assertion that an unrelated person gave consent. The responsible customer/technician remains responsible for applicable organisation/employee notices and upstream-controller instructions. Existing attributed personal-consent/withdrawal routes remain available where used. Actual server-enforced permission, target, publication, native-capability and local-opt-out refusals remain boundaries. Removal of a local veto never supplies a telemetry request or new grant. Explicit Light/Full tier selection is required; older grants are not silently migrated. Genuine unattended-work, financial and native-access decisions retain their separate unchanged controls.
Annex: measures, recipients and end of processing
OpalSpan uses Auth0 authentication with OpalSpan-controlled workspace membership, roles and target authorisation/revocation. Native remote access uses encrypted SSH/SFTP through an outbound HTTPS relay. Hosted tools operate within the authorised human/workspace/device scope. Diagnostic collection is explicit, not routine unrestricted collection.
Conversation payloads and checkpoints use application data protection scoped to the workspace and conversation. Mech files use a private store outside public web roots with scoped access and file-integrity/version checks. Metadata-only access audit is separate from case content and conversation history. These measures do not represent a certification, an all-data encryption claim or a guarantee against every incident.
AWS supplies Bridge hosting in Stockholm (Lightsail eu-north-1) and the CloudFront front door under Ready IT's ordinary AWS account terms, including the incorporated applicable AWS DPA/SCC provisions.
OpenAI Ireland Ltd. supplies the Responses API for instructed hosted Mech
processing. The ordinary Services Agreement, updated 1 December 2025 and
effective 1 January 2026, incorporates the DPA through section 5.3. DPA section
4.1 supplies SCC or Article 45 adequacy arrangements for the EEA onward
transfers it covers. The project uses Global residency and Standard tier, with
store=false; the organisation's model-feedback, evaluation/fine-tuning and
API-input/output sharing opt-ins are all disabled. Provider abuse-monitoring
and prompt-cache retention remain distinct from OpalSpan's stored conversation
history. Neither provider is described as universally EU-only or zero retention.
AWS hosting and OpenAI model processing are relevant subprocessors for the customer technical-work data they receive. Auth0's role in instructed user identity processing must be distinguished from Ready IT's own account administration. Microsoft 365/Graph receives contact correspondence and contract mail; it is a subprocessor under this agreement only to the extent Ready IT instructs it to process the customer's controlled data on the customer's behalf. Stripe's own payment/legal processing is not automatically a technical-work subprocessor relationship.
For Microsoft Exchange Online/Graph processing within this agreement's scope, the ordinary Microsoft agreement incorporates the Products and Services DPA. Its May 2026 Data Transfers provisions cover the United States and other Microsoft/subprocessor operating countries with the stated location safeguards and 2021 SCCs for EEA transfers. The DPA identifies the Microsoft Ireland Operations Limited to Microsoft Corporation SCC arrangement; those transfer entities are not an invented description of Ready IT's billing counterparty. Contract-mail application sending permissions are restricted to one mailbox.
Okta supplies Auth0 authentication and sign-in identity processing from an EU tenant; OpalSpan separately controls workspace membership and permissions. Its role in customer-instructed identity processing is distinct from Ready IT's own account administration. Supplier support and onward processing may occur outside the EEA. Okta's published processing and transfer information is at https://www.okta.com/legal/trustandcompliance/.
General subprocessor authorisation applies to the identified on-behalf processing and its applicable arrangements, not an undisclosed additional purpose. Supplier terms/safeguards can be obtained through contact@readyit.dk.
The customer may send specific instructions, rights requests and an end-of- service return/deletion choice to contact@readyit.dk. Directory/case records have no general automatic expiry; scratch-file expiry, access-audit retention and financial records follow their distinct purposes. The end-of-processing obligation below is not replaced by those application timers.
Ready IT verifies the requesting party's authority and the affected customer and workspace before carrying out a return, deletion or restriction instruction. The action and any applicable retention exception are recorded. Live service records and recovery copies may need different handling: automatic snapshots rotate over seven daily generations, while separate manual recovery copies are reviewed individually and have no automatic expiry. An end-of-processing return or deletion instruction covers the relevant recovery copies, subject to the legal-retention exception in clause 6. Before restored data is returned to use, completed deletion and restriction instructions for the affected scope are reconciled. Ready IT will explain the route and any remaining lawful exceptions for a specific request.
Required processing terms
Ready IT processes personal data only on documented controller instructions, including instructions on transfers outside the EU/EEA, unless applicable Union or Member State law requires otherwise. In that case it informs the controller of the legal requirement before processing unless that law prohibits notification on important public-interest grounds.
Persons authorised to process personal data must be committed to confidentiality or subject to an appropriate statutory confidentiality duty. Ready IT implements the measures required by GDPR Article 32.
The controller gives general written authorisation for the subprocessors identified in the completed annex. Ready IT informs the controller of intended additions or replacements so the controller has an opportunity to object. No undisclosed list or blank annex establishes authorisation for a supplier. Ready IT imposes the same applicable data-protection obligations by contract on subprocessors, including sufficient guarantees for appropriate technical and organisational measures, and remains responsible to the controller for the subprocessor's performance of those obligations.
Taking account of the nature of processing, Ready IT assists the controller through appropriate technical and organisational measures, insofar as possible, to fulfil obligations to respond to data-subject rights requests. It assists compliance with GDPR Articles 32-36, taking account of the nature of processing and information available to it.
Ready IT notifies the controller without undue delay after becoming aware of a personal-data breach. This does not replace the controller's own applicable notification and communication obligations.
At the controller's choice, Ready IT deletes or returns all personal data after the end of the processing services and deletes existing copies unless Union or Member State law requires retention. The actual return/deletion and backup arrangements must be recorded consistently with this obligation.
Ready IT makes available information necessary to demonstrate compliance with GDPR Article 28 and allows for and contributes to audits, including inspections, conducted by the controller or an auditor mandated by it.
Ready IT immediately informs the controller if, in its opinion, an instruction infringes GDPR or other Union or Member State data-protection provisions.