OpalSpan: customer technical-work processing instructions
Version: dpa-instructions-en-2026-10-04-v5. Applicable agreement: dpa-en-2026-10-04-v5.
These instructions apply to personal data you instruct Ready IT ApS to process on your behalf through the OpalSpan customer technical-work service. They do not make you controller merely because you buy a plan, and do not replace the privacy notice for Ready IT's own account, security and billing processing.
Processing defaults for this order
OpalSpan asks no separate buyer-kind, personal-data-role or processing-purpose questionnaire. Stripe's native company/tax-ID collection is the sole buyer-type control. An order without native business details defaults to personal or household use. An order with native business details defaults to commercial use and acceptance of the applicable DPA and these instructions.
These are product defaults inferred from the native Checkout record, not separate customer declarations and not proof of legal consumer status, representative authority, controller status or upstream instructions. A business using OpalSpan for another controller remains responsible for having the necessary authority and instructions. Do not enter private customer contracts, credentials or unrelated personal data into Checkout fields. Contact contact@readyit.dk before using a personal/household workspace for customer-controlled processing.
Instructions for applicable customer-controlled processing
You instruct Ready IT to host, organise and make available your authorised customer/contact, case and technical-work records; enable authorised remote technical access; and process relevant data with the service providers and measures identified in the applicable completed DPA annex.
When you request hosted OpalSpan Mech, your instructions include supplying relevant conversation/context and tool evidence to OpenAI's API for responses and authorised direct-tool work. Relevant material may span cases within the authorised workspace. This is not a request for EU-only or zero-retention processing, and separate chats are not separate confidentiality boundaries. It does not authorise processing outside the purposes and data covered by your lawful instructions.
Exact prospective monitoring instruction
The additional purpose is device_health_monitoring in your actual capacity as controller or authorised processor. Present complete new document copies and material changes and obtain the original holder's explicit instruction for the exact workspace/devices, pack binding SHA256, privacy-en-2026-10-04-v5, dpa-instructions-en-2026-10-04-v5, current policy revision and future-enrolment choice. Original-holder issuer/subject is checked against the retained order before consumption. The instruction records that authenticated identity/actor, purpose/capacity, sorted targets, request/digest, version, confirmation and time. Complete prior contracts and holder identity remain intact. A current Admin role is not original-holder authority; a removed holder retains contract rights without gaining workspace/device access.
The eight current signal families are presence, free volume percentage/bytes/ system-volume trend, new crash/reboot indication, optional disk-warning code and thermal pressure. Factual per-OS sources, local metadata projection and unavailable/excluded values are specified in privacy-en-2026-10-04-v5. Raw file/report/log content, paths, application/user names, software inventory, commands, secrets, memory/update/protection/threat-name data are not this feed. Technical hashes are pseudonymous, not anonymous or guaranteed unlinkable.
You instruct Ready IT to host/display this minimised metadata on its existing Bridge/AWS service under current member/device authority, evaluate deterministic sustain/rearm/cooldown/dedup/storm rules and use only necessary alert/signal/ threshold context in an actually authorised Mech run. Neither collection nor deterministic evaluation sends a model feed or uses AI/device-work units. Existing OpenAI terms/retention apply to selected authorised-run material; ordinary diagnostics keep their explicit scope. Rescue is excluded. Missing sensors/data is unavailable, not healthy.
Historical readings/deltas expire seven days from measurement; events/alerts thirty days from recorded occurrence; bounded ingestion receipts thirty days from receipt. Latest non-event state is separate while enrolled and remains stale/timestamped after off. Native spool maximum64batches/256KiB expires seven days from original sample age during operation/next startup and clears on acknowledgment/off. Stopped devices cannot be remotely wiped. Latest baseline, authority and bounded dedup cursors are protected enrollment metadata, not a report archive. Retirement/deletion or transfer removes the affected server latest data/authority. Return/deletion/recovery duties below are unchanged; case/conversation/required financial and authority evidence are separate, not retention of the complete expired feed. Limits may prune history earlier.
Desired default-on operates only inside lawful recorded boundaries. For each device, the relevant user separately supplies informed consent for that device/ notice, or a qualified authorised human records evidence of technical necessity for monitoring expressly requested by that user. Membership, an employer/ customer statement, purchase, old enrollment, publication, silence or opt-out alone is neither consent nor necessity. Ready IT keeps its own obligations; a DPA instruction does not waive terminal-access requirements. The implemented consent path accepts the signed-in device user's own issuer/subject, not a model/technician claiming an unrelated user consented. If the user lacks an authorised account/path, that device stays pending/off; no invented consent. Necessity needs the actual express request and evidence, not an enrollment- wide exemption.
Device evidence binds workspace/device, notice version and whole-pack hash, user-subject/evidence hashes, recorder, time/optional expiry and current revision. Private approval additionally binds the active instruction digest. Changed payload/target/version/role or expired approval needs a new review. Missing, withdrawn, expired or mismatched evidence and native local opt-out keep collection off. A changed publication hash does not silently migrate consent. Per-device/bulk controls remain; workspace default applies only to future enrolments and creates no user consent. Transfer discards old workspace telemetry/consent rather than carrying it to another holder.
Exact unattended-work instruction
Configure each Automation prospectively with actual targets, objective, schedule/alert, timezone/recurrence, model/reasoning, scope and whole-run AI and monetary budgets. Exact review binds those values plus applicable document/ quote hashes, owner/role revision, configuration revision, request and expiry. Only a genuine human approves the protected review or existing Mech decision; approval grants no role. Paid-session overage defaults zero and requires billing authority. Consumed confirmation commits with immutable configuration evidence; later wake/run monetary policy derives from it, not a model claim.
One continuing Mech conversation is created when needed. Each wake has frozen trigger/configuration and current targets/authority/model, independent budgets, state/result and shared accounting. Only necessary bounded history/context is used. Model/tool dispatch and reentry check current authority/local consent/ aggregate budgets. Unattended runs cannot approve/enlarge their own scope. Pause/change/delete ends/changes the instruction; adoption is explicit with a new exact review. Do not replay uncertain device work or treat history as a new run's permission.
Mail excluded from this instruction
This package does not instruct Automation notifications or critical email. Use private conversation/results for independently authorised schedule/monitoring. Existing contact/contract/rights mail remains in its original scope. No SES, new Graph purpose, mailbox permission or real send is authorised. Future critical-member mail needs separate actual purpose/retention/recipient/body evidence; disabling it does not block schedule/monitoring.
Where you are a processor for someone else, you may issue these instructions only within your authority and that controller's instructions, including the applicable permission to use subprocessors. Consumer/business purchasing capacity is not a declaration of this data-protection role.
Use contact@readyit.dk for specific instructions, rights assistance and your return/deletion choice when the processing service ends. Ending payment while continuing to use Free does not by itself instruct erasure.
For customer or organisational work, the electronic acceptance statement is:
I accept the OpalSpan data processing agreement and instructions for customer-controlled personal data that I instruct Ready IT ApS to process through OpalSpan. Where I act for another controller, I am authorised to give those instructions.
The concise Stripe acceptance label links this agreement and these instructions for native business orders. OpalSpan records that native acceptance and the commercial-use default; it does not claim that the customer separately declared a processing role. Earlier-holder additions use the attributable private feature instruction above. Public changes do not rewrite original orders, silently migrate consent/tariffs or waive statutory rights.
This statement operates with the completed applicable annex; it does not authorise an undisclosed supplier, unrecorded international-transfer route or additional processing purpose.