Product
Litigation
- Early Case Assessment
- Evidence Analysis
- Web Search
- Document Review
- Production Setup
- Connectors (Upcoming)
- Legal Research (Upcoming)
Transactional
- Contract Review
- Contract Intelligence
- Word Add-In
- Web Search (Upcoming)
- Connectors (Upcoming)
- Legal Research (Upcoming)
Solutions
Litigation
- Early Case Assessment
- Investigations & Subpoenas
- Trial Preparation
- Enterprise eDiscovery
- Cloud eDiscovery
Transactional
Who it’s for
Resources
Learn
Customers
Events & CLE
Extract cloud hosting obligations by reading the complete contract package, separating provider commitments from customer duties, and recording each actionable requirement with its trigger, timing, dependencies, and pinpoint source. Assign an internal owner and specify the evidence needed to demonstrate performance or preserve a remedy. The deliverable is a source-linked obligations register for legal, infrastructure, security, procurement, and finance. Keep unresolved interpretations visible: an uptime percentage or retrieval period is not operationally useful without its service scope, conditions, and exceptions.
When to use this workflow
Use this customer-side workflow after signing, when taking over an existing hosting relationship, or when an amendment changes service levels, support, security, or exit rights. It is especially useful when separate teams control deployment architecture, outage evidence, invoice receipt, and contractual notices.
This is a US-focused transactional workflow, not litigation procedure or advice for a particular matter. Rights depend on the actual agreement, governing law, service configuration, and facts. Distinguish required performance from optional actions needed to exercise a right. Keep sector-specific legal requirements separate from extracted contract duties and confirm their applicability.
What you need
Assemble the executed master agreement, orders, SLA, support terms, security schedules, applicable DPA or BAA, amendments, and incorporated online terms. Include notice and precedence provisions, not just operational schedules.
Obtain these operational inputs:
- Covered services, account and resource identifiers, regions, architecture, and workload owners.
- Billing-cycle definitions, invoice-routing records, and authorized notice contacts.
- Incident logs, maintenance notices, support cases, and evidence-retention arrangements.
- Committed terms, renewal information, planned migrations, and approval responsibilities.
Preserve the version incorporated into the agreement, together with any applicable later modifications. A live provider page does not establish historical wording for an October 13, 2026 review. Record unavailable documents as gaps rather than assuming their contents.
Use the template
Copy the Cloud Hosting Agreements — Obligations register table into your working document or spreadsheet. This is a user-maintained working record, not a promised software module.
| ID / type | Actor / owner | Action / service | Trigger / timing | Conditions | Pinpoint source | Source text | Evidence / status |
|---|---|---|---|---|---|---|---|
Use stable row IDs so tickets and calendar entries can refer to the same obligation. “Type” distinguishes a customer duty, provider promise, conditional right, or internal task. “Actor” identifies the contractually responsible party; “owner” identifies the customer role responsible for performing or checking it.
The source field should identify the preserved document, version, section, page, and table row where relevant. Retain operative text separately from the normalized action. For lengthy provisions, reference a preserved extract containing the relevant qualifications.
Record a deadline formula before entering a calculated date. Put dependencies and linked row IDs in “Conditions.” Use “Evidence / status” for completion proof, uncertainty, assigned reviewers, and disposition. Create event-specific records linked to the master row when an outage or notice activates it. Distinguish extraction verified, performance pending, and performance complete.
Step by step
1. Establish the authoritative contract package
Create document IDs and a version index. Confirm execution, effective dates, covered orders, amendments, and incorporated documents. Read precedence provisions before resolving conflicting wording. Keep superseded versions distinguishable from operative versions.
For example, the AWS Customer Agreement, section 11.2, incorporates policies and gives Service Terms precedence over the agreement. This is document-specific wording, not a universal hierarchy or an enforceability conclusion. (aws.amazon.com)
Check whether a negotiated order changes a general provision and whether an online amendment has become applicable. Do not replace the executed package with whichever webpage is easiest to retrieve.
Register output: source IDs and an assigned gap entry for each missing document that could change an obligation. Do not describe inaccessible wording as “not present.”
2. Extract independently actionable requirements
Read each operative clause for actor, action, trigger, timing, and qualification. Split independently performable actions. A maintenance-notice promise and a credit-request procedure need separate rows even though both concern availability.
Distinguish promises, definitions, exclusions, rights, and internal recommendations. “Unavailability” generally supplies a measurement dependency, not an independent duty. A termination option does not require the customer to terminate.
Check hosting-specific subjects: availability, incident reporting, support escalation, customer security controls, backup allocation, payment, maintenance, renewal, and data retrieval. Do not infer that hosting includes backups or restoration assistance merely because those services would be useful.
Register output: separate actionable rows with operative text, normalized actions, and explicit types. Identify internal recommendations as internal tasks rather than contract requirements.
3. Attach service scope and eligibility conditions
Map each row to the relevant service layer, workload, region, deployment, or order. Ask whether the customer uses the configuration necessary for the commitment to apply. Preserve the contractual performance standard, including an efforts qualification where present.
The Amazon Compute SLA, “SLAs” and “SLA Definitions”, distinguishes qualifying multi-zone deployments from individual instances and measures unavailability through external connectivity. Its commitments therefore should not be recorded as application-response guarantees. (aws.amazon.com)
Cross-reference definitions and exclusions. Ask infrastructure to confirm architecture and telemetry rather than treating the contract description as proof of actual deployment. Match any proposed exclusion to the incident facts before treating it as applicable.
Register output: covered service, eligibility conditions, linked definitions, and an assigned technical question wherever configuration or measurement remains unverified.
4. Translate timing into a reproducible rule
Record the initiating event, receipt rule, contractual interval, submission channel, and required supporting material. Distinguish invoice date from invoice receipt and billing cycle from calendar month. Identify any specified time zone; escalate material counting ambiguity rather than inventing a convention.
The Amazon Compute SLA credit procedure requires receipt by the end of the second billing cycle after the incident and specifies claim information. This is a contractual procedure, not a statutory limitation period. (aws.amazon.com)
By contrast, the CyrusOne–Q2 infrastructure SLA, section II(c), requires a written request within 90 days after receipt of the relevant invoice. That historical colocation agreement does not establish a general cloud deadline. (sec.gov)
Register output: timing formula, verified trigger evidence, calculated date when supportable, submission route, and missing prerequisites. Label earlier internal targets separately from contractual deadlines.
5. Assign responsibility and completion evidence
Give each actionable row one accountable internal owner. Infrastructure may collect logs, finance may establish invoice receipt, and legal may check notice wording. Identify contributors without substituting shared ownership for accountability.
For provider promises, assign a customer owner to verify performance—not to perform the provider’s duty. Specify inspectable evidence: a maintenance notice with receipt metadata, support-case acknowledgment, validated export, or credit appearing on an invoice. An email showing dispatch may not prove the receipt event specified by the agreement.
Set checkpoints through existing team processes. Extraction does not itself create reminders or establish performance.
Register output: contractual actor, accountable customer owner, contributors where needed, and an evidence standard. Record any retention gap that could prevent later verification.
6. Reconcile dependencies and remedy limitations
Read linked provisions together. Credit rights may depend on eligible deployment and complete submissions. Record any fee base, cap, non-stacking rule, or exclusivity provision that changes how the right operates, without turning the register into a full damages analysis.
Exit access also needs qualification. The AWS Customer Agreement, section 5.3(b), conditions retrieval on payment and excludes termination by AWS under section 5.2(b). Such wording is not an unconditional migration guarantee. (aws.amazon.com)
For HIPAA-covered relationships, HHS guidance, questions 1 and 10, advises consistency among the SLA, BAA, and HIPAA requirements, including access to ePHI. It distinguishes negotiated audit assurances from audit rights expressly required by HIPAA. (hhs.gov)
Register output: linked dependencies, conflicts, and an assigned legal decision owner. Keep contractual conditions and potentially overriding legal requirements separately identified.
7. Test the register against operational events
Walk through an outage, scheduled maintenance, and a termination or export scenario relevant to the services. Can the owner identify the applicable commitment, verify eligibility, retrieve its source, and assemble required evidence without reconstructing the agreement?
Have legal verify interpretation and the operational owner verify feasibility. If required logs cannot be retrieved or receipt cannot be established, assign a corrective action. Mark extraction complete only when its sources and interpretation have been checked; performance may remain pending.
For an amendment, identify affected rows and preserve their prior versions rather than overwriting the history needed to assess earlier events.
Register output: extraction status, test findings, evidence location, and closure or an assigned open issue. Retain the rationale for material interpretation decisions.
Worked example
Fictional scenario: Alder Quay Analytics buys hosting from Cirrus Vale Hosting for a customer dashboard. All parties, documents, clauses, and events below are fictional. The executed package contains order O-01 v1 and SLA S-02 v1; incorporated exit schedule E-03 is missing.
S-02 §4 conditions credits on concurrent unreachability of both dashboard instances. Section 4(a) requires portal submission within 15 calendar days after receipt of the affected invoice. Section 6 requires five calendar days’ written notice of scheduled maintenance. These invented terms are not market-standard evidence.
Infrastructure has logs for only one instance. Finance has the invoice PDF but no verified billing-inbox receipt record. Operations also wants to approve a post-termination export timetable.
| ID / type | Actor / owner | Action / service | Trigger / timing | Conditions | Pinpoint source | Source text | Evidence / status |
|---|---|---|---|---|---|---|---|
| CH-01 / conditional right | Customer / finance lead | Submit dashboard credit request | Invoice receipt + 15 calendar days | Both instances concurrently unreachable; portal submission | S-02 v1, executed, §4 and §4(a), p.2 | §4: “Credits require concurrent unreachability of both dashboard instances.” §4(a): “Customer must submit its request through the support portal within 15 calendar days after receipt of the affected invoice.” | Open: infrastructure to obtain second-instance logs; finance to verify receipt. Eligibility and date unverified. |
| CH-02 / provider promise | Provider / operations lead | Give scheduled-maintenance notice | At least five calendar days before maintenance | Scheduled maintenance only | S-02 v1, executed, §6, p.3 | “Provider will give written notice at least five calendar days before scheduled maintenance.” | Pending: operations to retain notice, receipt evidence, and planned start; compare interval before assessing compliance. |
| CH-03 / internal task | Customer / legal lead | Obtain exit schedule before export-plan approval | Before internal approval; not a contractual deadline | E-03 unavailable | O-01 v1, executed, §8, p.4 | “Post-termination retrieval is governed by Exit Schedule E-03.” | Open: procurement to obtain E-03; legal to extract conditions. No retrieval period established. |
The source references change the decisions. Finance cannot substitute the printed invoice date for receipt. Infrastructure cannot use one instance’s logs to establish concurrent loss. Legal cannot approve the export timetable based on an assumed retention period. The third row records an internal response to missing evidence, not a contractual duty to obtain a document. None of these entries establishes credit entitlement or guaranteed continued access.
Common mistakes
- Recording only the uptime percentage. Attach architecture, measurement definitions, performance qualifications, and covered services.
- Combining performance and remedy procedures. Separate the provider promise from claim submission, then link their conditions and owners.
- Treating optional rights as mandatory actions. Label credit requests and termination elections as conditional rights; record any resulting duties separately.
- Using current webpages as historical evidence. Preserve applicable versions and assign uncertainty about modifications.
- Calling missing wording absent. Distinguish reviewed documents without a provision from missing schedules or unreadable attachments.
Final quality check
- Each operative row identifies a preserved version and precise clause or table location.
- Source text supports the action and its material qualifications.
- Technical owners have checked covered services, architecture, and measurement inputs.
- Timing preserves the actual trigger, receipt rule, channel, and submission requirements.
- Duties, promises, conditional rights, and internal tasks remain distinguishable.
- Owners have accepted responsibility and completion evidence is specified.
- Missing sources and conflicts are resolved or explicitly assigned; extraction status is separate from performance status.
Complete the workflow with DecoverAI
DecoverAI is the Legal Intelligence Platform for litigation and transactions. Its contract review supports review in Word using the represented party and deal-specific instructions; findings quote clauses, locate text, and rank severity. Tabular review supports work across multiple documents. Lawyers retain responsibility for validating obligations, interpreting dependencies, and assigning owners in their working register. To assess this workflow against a hosting contract package, book a demo.
Frequently asked questions
Should the register include provider obligations?
Yes. Identify the provider as actor and assign a customer owner to verify performance. Otherwise maintenance notices, incident responses, and exit commitments may lack an accountable internal recipient.
How much source text should each row retain?
Retain enough to verify the action and qualifications, with linked extracts for longer provisions. Include relevant definitions and cross-references. A section number is insufficient if the operative version cannot be retrieved.
What if a claim deadline cannot yet be calculated?
Keep the contractual formula, identify missing trigger evidence, and assign an owner to obtain it urgently. Use a clearly labeled conservative internal target while legal assesses uncertainty; do not present it as the established contractual deadline.
Does encryption remove the need to examine a BAA?
No. HHS guidance, question 2, explains that a provider maintaining ePHI for a covered entity or business associate is a business associate even without the decryption key. Determine applicability and review the required BAA alongside hosting terms. (hhs.gov)
Sources
- Amazon Compute Service Level Agreement — service scope, definitions, and claim procedures.
- AWS Customer Agreement — precedence and conditional retrieval.
- CyrusOne–Q2 infrastructure SLA, SEC Exhibit 10.12.1 — historical colocation claim procedure.
- HHS Guidance on HIPAA & Cloud Computing — covered relationships and contractual consistency.
This guide is general information about legal workflows, not legal advice for any matter. It was drafted and reviewed with AI assistance. The worked example is fictional. Contract rights and procedure depend on the governing law, the actual wording, and the facts, so check the cited sources and the rules that apply in your jurisdiction before relying on it.
