01Why a SaaS template does not fit

A typical DPA assumes the vendor operates the application, holds the data in their schema, and processes it on your instructions. Almost none of that describes renting a GPU.

With compute you generally hold root on the machine, install your own stack, and put data there yourself. The provider supplies the environment. That inverts several assumptions: the provider may have no visibility into what data exists, no ability to identify a data subject within it, and no practical means of fulfilling an erasure request on your behalf.

A template that assumes otherwise creates obligations neither side can meet, which is worse than a shorter agreement that is accurate. The goal is a document that describes what actually happens.

02Establish the roles first

Everything else follows from this, and it is the clause most often left ambiguous.

Under India’s DPDP Act the party determining the purpose and means of processing is the data fiduciary, and the party processing on its behalf is the data processor. In a compute rental you are almost always the fiduciary for the content you place on the machine, and the provider is a processor for the limited personal data it handles to operate the service — your account details, billing, support correspondence, access logs.

Two roles, not one, and they cover different data. Write that distinction explicitly. If the agreement implies the provider is a fiduciary for your customers’ data, or that you are somehow responsible for the provider’s billing records, the rest of the document will be incoherent.

Our post on what the DPDP Act asks of you covers the duties that attach to the fiduciary role, which remain yours regardless of who runs the hardware.

03Scope: what the provider touches

Vague scope is the most common defect. “Customer data” is not a definition when the provider cannot see inside your instance.

Separate the categories and name them:

That last row deserves attention. Support tickets are where instance content most often leaks into the provider’s systems, because someone pastes a log or a sample to explain a problem. Deciding that in advance is better than discovering it in a retention review.

04Access, and under what conditions

Ask for enumerated conditions rather than a standard of reasonableness. “As necessary to provide the service” is not a limit; it is a permission.

A usable clause states that provider personnel do not access the environment in ordinary operation, and lists the exceptions: at your request, to respond to a specific abuse or security incident, or where compelled by law. It says whether you are notified, and it says who at the provider is authorised.

Our own position is published rather than negotiated per customer: Privacy Policy §5 states that our personnel do not log into your Instance, inspect its filesystem or read Customer Content in the ordinary course of operating the platform, and sets out the defined conditions under which they may. You can read it before signing anything, which is the point.

05Sub-processors and change notice

Every provider uses sub-processors. Payment processing, email delivery, analytics, and possibly parts of the infrastructure. The question is not whether but whether you are told.

Three things to require. A current list, not a promise to maintain one. Advance notice before a sub-processor is added or changed, with enough time to react. And a right to object, with a stated consequence — usually the right to terminate without penalty if you cannot accept the change.

Notice periods of thirty days are common and workable. Anything that lets the provider change sub-processors silently means your own compliance documentation is out of date the moment they do.

06Deletion, export and what happens at the end

The clause people read last and need most.

What happens to instance content on termination? When is storage wiped, and by what method? Is there a grace period during which you can still retrieve data, and how long?

What retention survives? Some records must be kept — tax and accounting law requires financial records for years, and a provider promising to delete everything immediately is either wrong or breaking a different law. A credible agreement states which categories are retained, for how long, and why.

Can you get your data out, and how fast? Egress limits and speeds matter when you are leaving. Establish this before you need it.

Ours are published with periods attached: access and security logs for 90 days, usage and billing telemetry for 13 months, support correspondence for 24 months, set out in the Privacy Policy. Specific periods are the thing to insist on; “as long as necessary” is not a commitment.

07Security commitments you can verify

Security sections attract adjectives. Prefer statements that could be shown to be false.

Useful: encryption in transit and at rest, named where it applies. Network isolation between tenants. Multi-factor authentication on administrative accounts. Logging of administrative activity. A breach notification commitment with a stated timeframe.

Less useful: “industry-leading”, “bank-grade”, “military-grade”. These are not claims, and a document full of them usually has fewer specifics elsewhere.

Ask directly which certifications the provider holds, and treat a straight answer as a good sign even when the answer is none. Our Privacy Policy states plainly that we make no claim to hold any certification or audit report we have not obtained — which is a more useful sentence for your procurement file than a vague assurance would be.

08A clause checklist

This is a practitioner’s checklist rather than legal advice, and a data protection lawyer should see anything you intend to sign. If you need something from us that our published documents do not cover, ask: privacy@vijaycloud.com.