Skip to content

The Standing DPA: Data Processor Status Under Zero Standing Privileges

6 min read
dpa data-processor compliance

Private AI Ltd acts as a Standing Data Processor under Article 4(8) UK GDPR, operating under a Zero Standing Privileges architecture. The standing Data Processing Agreement is operative continuously from signature — audit rights, breach notification, Article 32 technical and organisational measures, confidentiality, and liability apply at all times. What the Zero Standing Privileges architecture provides is not non-processor status, but a precisely engineered constraint on when and how active processing can occur.

For why AI vendor Data Processor status triggers mandatory UK GDPR obligations — and why those obligations compound into an existential compliance burden for cloud AI vendors — read our parent article. This piece explains exactly how the standing DPA and Zero Standing Privileges architecture work together, clause by clause.


The Default Operating State

The DPA’s foundation is a contractual acknowledgement of architectural reality. In the Default Operating State, Private AI Ltd holds no active connection, no credentials, and no means of accessing Client systems.

The “Default Operating State” is a defined term: the state in which Private AI Ltd has completed Zero-Touch Provisioning, all credentials have been revoked by the client at handover, and no Just-In-Time Support Session is in progress. No root passwords. No SSH keys. No API tokens. No credentials of any kind.

This is not a promise to refrain from accessing data. It is an architectural fact. The client revoked every credential at handover. Private AI Ltd cannot reach the server, the storage, or the application — regardless of intent.

Although the standing DPA is continuously operative, Private AI Ltd’s active processing of Client Data in the Default Operating State is zero. Your firm must include Private AI Ltd in its Article 30 Records of Processing Activities as a Standing Data Processor — but the processing record for the Default Operating State accurately reflects no active data access.


Over-the-Shoulder Support — No Active Access

The firm’s standard support channel is Over-the-Shoulder (OTS) Support. The client’s IT lead executes all commands on the firm’s own systems while sharing a screen with Private AI Ltd’s engineer via video call.

The standing DPA is explicit on four points regarding OTS:

  • Private AI Ltd’s engineer may observe the client’s screen but does not operate, access, or control any system
  • No active processing of Personal Data by Private AI Ltd occurs during OTS
  • OTS Support does not constitute a Level 1 or Level 2 access event under Schedule 2
  • Private AI Ltd’s engineer remains bound by the MSA’s confidentiality obligations regarding any information incidentally observed

The Clean Screen and Dummy Data Policy Schedule — executed as part of the service agreement — contractually prohibits the client from displaying live personal data, unredacted conversation logs, or live document content during screen-sharing sessions. The client’s IT lead must use only the system terminal, script execution output, and service status logs.


Just-In-Time Support — Level 1 and Level 2 Access

If OTS Support proves insufficient, the client may request Just-In-Time (JIT) Support. This is the scenario where Private AI Ltd temporarily performs active processing under Schedule 2 of the standing DPA. The standing DPA governs this access under a tiered instruction model.

The access sequence:

  1. The client creates a time-limited, auditable credential
  2. The client grants Private AI Ltd temporary logical access to specified systems
  3. A Level 1 or Level 2 access event occurs, as defined in Schedule 2 of the standing DPA
  4. Private AI Ltd performs the authorised maintenance operations

Active processing by Private AI Ltd is ruthlessly constrained.

Access scope: Limited to logical maintenance of system binaries, services, configuration files, and system logs. Private AI Ltd shall not query, search, extract, or copy any Client Data or Personal Data.

Processing acknowledged: Incidental viewing of system logs that may contain fragments of Personal Data — usernames, IP addresses, session identifiers — constitutes processing. The standing DPA confines Private AI Ltd’s active processing to that incidental viewing only.

Prohibited activities: During any JIT session, Private AI Ltd is strictly prohibited from extracting, copying, downloading, querying, or exfiltrating any Client Data; remotely storing any data on Private AI Ltd’s own systems; accessing databases, data stores, or application-layer repositories without express written instruction; and taking screenshots or any reproduction of information displayed on client systems.

No persistent access: Private AI Ltd shall not install backdoors, persistent agents, remote access tools, or any mechanism enabling future access without a fresh authorised access event.

No commingling: Any Personal Data incidentally viewed shall not be recorded, noted, or combined with any other data held by Private AI Ltd.


Credential Revocation and Session Logging

Upon completion of the JIT support task, the client immediately revokes Private AI Ltd’s credentials. The Qualifying Support Event is logged in the register maintained under the standing DPA. The firm receives an updated copy of the Qualifying Support Event Register within five business days, documenting every JIT session — date, time, duration, personnel, systems accessed, activities performed.

The standing DPA mandates that Private AI Ltd generate and securely retain encrypted terminal session logs and screen recordings of each JIT session, strictly for compliance audit, demonstrating scope of activities, security incident investigation, and satisfying audit requirements of the client or the ICO.

These Session Logs are encrypted at rest, stored in a dedicated access-controlled repository, made available to the client on written request, and securely destroyed within twelve months in accordance with NCSC guidance on secure sanitisation.


What This Means for Your Compliance Officer

The standing DPA is operative continuously from signature. Unlike cloud AI vendor DPAs, it is not characterised by an opaque sub-processor chain or ongoing active data flows. The Zero Standing Privileges architecture means:

  • Active processing by Private AI Ltd is limited to authorised JIT Support Sessions — a scenario that may occur once or twice per year, for sessions lasting minutes
  • In the Default Operating State, Private AI Ltd holds no active access, no credentials, and no network path to Client systems
  • Every JIT access event is logged, time-bounded, credential-scoped, and independently verifiable
  • The standing DPA audit rights, breach notification obligations, and Article 32 measures apply throughout — protecting the firm at all times

Your Compliance Officer documents the standing DPA once and includes Private AI Ltd in the firm’s Article 30 register as a Standing Data Processor. The processing record for the Default Operating State reflects zero active data access. For JIT events, the Qualifying Support Event Register provides the audit trail.

Talk to our team to review the full standing DPA and understand how Zero-Touch Provisioning integrates with your firm’s existing data governance framework.


Private AI Ltd (SC881079) acts as a Standing Data Processor under Article 4(8) UK GDPR, operating a Zero Standing Privileges architecture. We deploy sovereign, zero-egress AI environments for regulated professional services. In the Default Operating State, we hold no active connection and no credentials to client systems.