Operator Support Access Policy

Product: Exceptao / paraKSCol / Cyberzgodnošć EDU  ·  Last updated: 2026-05-22

1. Purpose — what support access is for

Operator support access exists for a single purpose: enabling the Operator to fulfil its support, incident-response, and platform-operation obligations under the Terms of Service and the DPA. It is support functionality only. It is not used:

• For sales, marketing, or product analytics;
• To inspect Controllers’ data on a routine or sampling basis;
• For training machine-learning models, building benchmarks, or evaluating product features;
• To respond to lawful access requests from public authorities (those are governed separately by the Government Requests Policy at /legal/government-requests and never use the impersonation mechanism described here).

2. Definitions

3. Authorisation model

Operator support access is available under one of three layers, each with progressively stronger controls and progressively stronger reporting obligations:

3.1 Layer 1 — Tenant-Admin Approval (default)

1. An Operator engineer submits an impersonation request through the platform-administration interface, providing: (a) the Target User, (b) the Incident reference, and (c) a written reason of at least 20 characters describing what they need to diagnose. The Operator engineer must pass step-up MFA at this step.
2. The platform records the request as pending and sends an email to every Tenant Admin of the Controller’s Tenant. The email contains the Operator engineer’s name and email, the Target User’s email, the Incident reference, the verbatim reason, an Approve link, a Deny link, and a 24-hour automatic-expiry timestamp.
3. Any Tenant Admin may approve or deny the request. Approval requires the Tenant Admin to pass their own step-up MFA. Approval activates the impersonation session immediately; denial closes the request permanently.
4. If no Tenant Admin approves or denies within 24 hours, the request expires automatically and is recorded as expired.
5. Once activated, the session has a hard expiry of 60 minutes (or such other duration as the Controller has configured in Tenant settings, between 15 minutes and 4 hours). The Operator engineer may end the session manually at any time and is contractually obliged to do so as soon as the diagnostic step is complete.

3.2 Layer 2 — Break-Glass (urgent, no admin response)

If a request was flagged urgent at creation and no Tenant Admin has approved or denied it within 24 hours, the Operator engineer may declare a break-glass escalation. Break-glass is subject to additional controls:

1. The Operator engineer must pass step-up MFA a second time and provide an additional written justification (at least 100 characters) explaining specifically why waiting further for Tenant-Admin approval would cause harm to the Controller.
2. The platform immediately emails every Tenant Admin, every email address marked as a security contact on the Controller’s Tenant, and the Operator’s own security alias.
3. The platform enters a 2-hour cooling period during which any Tenant Admin may veto the break-glass. Veto requires the Tenant Admin to pass step-up MFA. A veto closes the request permanently and triggers a 24-hour lockout: the Operator engineer cannot request impersonation on the same Tenant for the next 24 hours unless the path escalates to Layer 3.
4. If the 2-hour cooling period elapses without veto, the session activates automatically. The audit row carries the permanent flag mode=break_glass.

3.3 Layer 3 — Emergency Access Event

Layer 3 exists for the residual case where a Tenant Admin is genuinely unreachable and the 2-hour break-glass cooling period would cause irreparable harm — for example, an active security incident in progress, an ongoing data-loss event, or a regulatory deadline that cannot be missed.

1. The Operator engineer must pass step-up MFA twice (two separate assertions 30 seconds apart, to make the action deliberate).
2. The Operator engineer must enter (a) a description of the nature of the emergency (at least 200 characters), and (b) an explanation of why the 2-hour break-glass cooling period is unacceptable in the circumstances (at least 200 characters).
3. The platform creates an Emergency Access Event record in the platform-level incident register. The event is visible to all platform operators, all Tenant Admins of the affected Controller, and is enumerated in the Operator’s next Transparency Report (see § 7).
4. The platform immediately emails every Tenant Admin, the Controller’s registered legal-entity email of record (the address provided at contract signing for formal notices), and the Operator’s own legal and compliance team.
5. The session activates immediately with a hard cap of 60 minutes and no extension possible.
6. Within 7 calendar days of an Emergency Access Event, the Operator MUST publish: (i) a post-incident report delivered directly to the affected Controller, and (ii) an entry in the public Operator Transparency Report (anonymised in aggregate but enumerating Emergency Access Events with their reasons).

4. Controller controls

4.1 Support access mode

Each Tenant has a support access mode setting, configurable by Tenant Admins at /settings/tenant/support-access. The three modes are:

A Tenant on forbidden causes every impersonation request to be refused by the platform regardless of Operator action. The Operator will be unable to diagnose tickets that require seeing the Controller’s data and may, in such cases, decline support requests that cannot be resolved by other means.

A Tenant on consent_only retains the standard Layer 1 approval flow but disables both break-glass and Emergency Access Event paths. In a true emergency where a Tenant Admin is unreachable, the Operator will not have any mechanism to act, and any consequent data loss or incident response delay is the Controller’s contractual risk.

4.2 Session duration

Tenant Admins may set the maximum impersonation session duration per Tenant, between 15 minutes and 4 hours. Default is 60 minutes. Shorter durations increase the diagnostic friction; longer durations increase the window of unsupervised access. The Operator’s recommendation is the default 60 minutes.

4.3 Visibility to the Target User

By default, the User whose session is being assumed is not directly notified at the moment of impersonation — the assumption is that they are the diagnostic target and may be offline or otherwise unavailable. The Controller may enable notify_target_user=true in Tenant settings to additionally email the Target User at impersonation activation.

4.4 Multi-admin recommendation

The Operator strongly recommends maintaining at least two active Tenant Admins per Tenant. A Tenant with a single Tenant Admin is at structurally higher risk of: (a) inability to approve legitimate support requests (delaying ticket resolution), and (b) inability to veto break-glass declarations (because there is no second authority to push back). The platform surfaces a non-blocking banner to Tenant Admins of single-admin Tenants reminding them to designate a second admin.

5. Audit transparency

5.1 Two-chain logging

Every state transition in the lifecycle of an impersonation request — creation, approval, denial, expiry, break-glass declaration, break-glass veto, break-glass activation, Emergency Access declaration, session activation, session end — is written to both:

• The Operator’s control-plane audit log (visible to platform operators, used for Operator internal review and external audits).
• The Controller’s own tenant audit log (visible to Tenant Admins via /audit and the audit-pack export endpoint).

The Controller can verify every minute of Operator access from its own audit log without contacting the Operator. The Controller does not need to trust the Operator’s control-plane log because the Controller’s own log carries the same events, written via an INSERT-only database role, hash-chained, and verifiable through the /api/audit/verify endpoint.

5.2 Action prefixing during active impersonation

While an impersonation session is active, every mutating action taken by the Operator engineer carries the action-code prefix platform_admin.impersonate.action. and embeds the Operator engineer’s user ID and email in the row’s metadata. The Controller can therefore distinguish, in its own audit log, between actions taken by its own users in the normal course of business and actions taken by an Operator engineer during an impersonation session.

5.3 Audit-pack export

The Controller’s audit-pack export endpoint includes all impersonation events for the period covered by the export, with the same prefix and metadata structure described above. Controllers may include impersonation-event review as a recurring item in their own internal audit programme.

6. Notification matrix

7. Transparency reporting

The Operator publishes a Transparency Report at /legal/transparency, updated at least annually, which discloses:

• The total number of Layer 1 impersonation requests in the reporting period, with median and 95th-percentile time-to-approval.
• The total number of Layer 2 break-glass declarations, with veto rate.
• The total number of Layer 3 Emergency Access Events, with anonymised summaries of the nature of each emergency.
• Government requests received and the Operator’s response (separate from this policy).

Aggregate numbers in the Transparency Report are anonymised across Tenants — the report identifies neither the affected Controllers nor the Target Users. Specific events are visible only to the affected Controller in its own audit log.

8. Operator engineer obligations

Operator engineers authorised to perform support access are bound by:

• The Operator’s internal Code of Conduct and Confidentiality Agreement, signed at the start of their engagement;
• The technical controls described in this policy — step-up MFA, incident reference, session expiry, audit logging — which they cannot bypass even with platform-administrator privileges;
• The contractual obligation to end impersonation sessions as soon as the diagnostic step is complete and never to let a session run to its expiry timer without active diagnostic work in progress;
• The Operator’s internal review process: every Layer 2 and Layer 3 event is reviewed by the Operator’s compliance lead within 5 business days, and abuse of the controls is grounds for immediate termination of the engineer’s authorisation.

9. Refusal to use the mechanism

If an Operator engineer determines that a support ticket can be resolved without impersonation — for example, by inspecting the Controller’s aggregate metrics, the platform’s own logs, or by guiding the Controller’s users through the diagnostic steps — they MUST do so. The choice between “diagnose by guidance” and “diagnose by impersonation” is not a convenience preference; impersonation is the more invasive option and is only used when the less invasive option is genuinely insufficient.

Operator engineers may not respond to a Controller’s request “please just log in as me and check” with an impersonation session unless the technical nature of the issue requires it. The Operator’s preferred alternative for Controller-initiated diagnostic requests is a pair-shared session via the Controller’s own video-conference tooling.

10. Changes to this policy

The Operator will notify Controllers of material changes to this policy at least 30 days before the changes take effect, consistent with the notification process in the DPA. Material changes are those that introduce new categories of Operator access, modify the approval flow, change the audit-logging scheme, or alter the Transparency Report obligations. Changes that further restrict Operator access or strengthen Controller controls are not material for notification purposes but are still published.

11. Contact