Cyber Laws and Regulations

Chapter 13
Cyber Contracts, Cloud Services and Third-Party Risk

Diploma in Cyber security
Cyber Laws and Regulations   •   Diploma

Cyber Contracts, Cloud Services and Third-Party Risk

Introduction

Modern organisations rarely operate all information systems themselves. They purchase infrastructure, software, storage, security monitoring, payment processing, communications and specialist support from external providers. Cloud computing and managed services can improve scalability and reduce capital expenditure, but they also transfer important operational dependencies outside the organisation’s direct control.

A cyber contract is therefore more than a commercial agreement. It is a governance instrument that allocates responsibility for confidentiality, integrity, availability, privacy, legal compliance, incident response and recovery. Poorly drafted contracts may leave an organisation unable to investigate an incident, recover data, prove compliance or obtain compensation for serious loss.

This chapter examines the principal contractual and due-diligence issues involved in cloud services and third-party technology relationships. Because legal requirements differ between jurisdictions, organisations should obtain advice on applicable privacy, telecommunications, financial-sector, employment, evidence, consumer-protection and cybersecurity laws.

Learning Objectives

By the end of this chapter, a learner should be able to:

  1. Explain why cloud and managed-service contracts create cybersecurity and governance risks.
  2. Identify important security, service-level, audit, data-location and subcontracting clauses.
  3. Evaluate confidentiality, indemnity, liability and insurance provisions.
  4. Apply a practical vendor due-diligence and risk-assessment process.
  5. Explain appropriate controls for termination, exit and data return.
  6. Analyse a third-party cloud incident and recommend contractual improvements.

1. Cyber Contracts as Risk-Allocation Instruments

A contract creates legally enforceable obligations between parties. In cybersecurity, it should answer five questions:

  • What must each party protect?
  • Which party performs each security activity?
  • How is compliance demonstrated?
  • What happens when something goes wrong?
  • How can the customer leave without losing access to data or operations?

The contract should be read together with its schedules, acceptable-use rules, data-processing agreement, service-level agreement (SLA), security addendum, pricing schedule and order form. A security promise in a marketing document is usually weaker than a specific contractual obligation with measurable remedies.

1.1 Shared responsibility

Cloud security is commonly described through a shared-responsibility model. The provider normally secures the physical facilities, core hardware and parts of the underlying platform. The customer remains responsible for matters such as identity management, access permissions, endpoint security, configuration, data classification and lawful use. Responsibility varies between infrastructure-as-a-service, platform-as-a-service and software-as-a-service.

A contract should convert this general model into a responsibility matrix. For every control, it should identify the accountable party, required evidence, reporting frequency and escalation route. Ambiguous statements such as “the provider maintains industry-standard security” are insufficient without defining the standard and its scope.

AreaCommon provider responsibilityCommon customer responsibility
Physical facilitiesBuildings, power, environmental controlsNone or limited inspection rights
Platform securityHypervisor, core network and infrastructureSecure configuration of workloads
IdentityPlatform authentication featuresUser lifecycle, privileged access and MFA configuration
DataStorage resilience and service operationClassification, lawful processing and access decisions
Incident responseDetecting provider-side compromiseCustomer investigation, notification decisions and containment
ContinuityPlatform redundancy and recoveryBackup strategy, recovery testing and business priorities

2. Contract Formation and Scope

Before signing, the parties should define the service precisely. The agreement should state the service environment, included features, geographic regions, dependencies, support levels, maintenance practices, permitted uses and exclusions. A vague scope can make it difficult to establish breach.

Important documents include:

  • Master services agreement: general legal terms.
  • Statement of work: specific implementation or professional services.
  • Service-level agreement: measurable performance commitments.
  • Data-processing agreement: processing instructions, privacy duties and subprocessors.
  • Security schedule: technical and organisational controls.
  • Business continuity schedule: resilience, backup and recovery commitments.
  • Exit schedule: migration assistance, deletion and transition obligations.

The order of precedence among these documents should be stated. Otherwise, a broad exclusion in the master agreement may conflict with a stronger promise in a security schedule.

3. Essential Security Clauses

3.1 Security programme and standards

The provider should maintain a documented information-security programme proportionate to the service risk. The agreement may reference recognised frameworks or standards, such as ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 2 controls, the NIST Cybersecurity Framework or sector-specific requirements. Certification is useful evidence, but it does not automatically prove that the customer’s particular environment is secure.

The clause should address governance, risk assessment, secure development, vulnerability management, malware protection, logging, access control, encryption, personnel screening, physical protection, backup, incident response and security awareness.

3.2 Access control and authentication

Contracts should require least privilege, role-based access, strong authentication for privileged accounts, periodic access reviews, prompt removal of departing personnel and controlled emergency access. The customer should understand whether provider administrators can access customer data, under what circumstances, and whether such access is logged and reviewed.

3.3 Encryption and key management

The agreement should specify encryption in transit and at rest, acceptable cryptographic practices, key ownership, key rotation, backup-key protection and procedures for compromised keys. Customer-managed keys can improve control but may create availability risk if keys are lost or disabled. The contract should define responsibilities for key recovery and emergency access.

3.4 Logging and evidence

Security logs should be sufficiently detailed to support detection, investigation and legal proceedings. Contractual questions include which events are recorded, retention duration, time synchronisation, customer access, export formats, protection from alteration and charges for retrieval. Logs can contain personal or confidential information, so their own access and retention must be governed.

3.5 Vulnerability and change management

The provider should maintain a process for vulnerability identification, risk ranking, patching, penetration testing and secure change control. The contract should distinguish emergency changes from routine changes and identify customer notification requirements. A provider should not be required to disclose sensitive exploit details in a way that creates additional risk, but it should provide enough information for the customer to assess exposure.

4. Service Levels and Resilience

An SLA converts availability and support expectations into measurable commitments. Typical measures include service availability, response time, restoration time, backup frequency, recovery point objective (RPO) and recovery time objective (RTO).

RPO is the maximum acceptable period of data loss measured in time. An RPO of four hours means that, following a disruptive event, the organisation aims to recover data no more than four hours older than the event, subject to the agreed architecture. RTO is the target time within which a service or function should be restored.

An SLA should define:

  • the measurement method and monitoring source;
  • scheduled-maintenance exclusions;
  • service credits and whether they are the sole remedy;
  • severity levels and support response times;
  • escalation procedures;
  • disaster-recovery testing;
  • dependencies and customer responsibilities; and
  • circumstances such as force majeure, abuse or unauthorised configuration changes.

Availability percentages can be misleading. A monthly availability target of 99.9% permits approximately 43.2 minutes of unavailability in a 30-day month, calculated as:

30 × 24 × 60 × (1 − 0.999) = 43.2 minutes

This calculation assumes a 30-day month and that the percentage is measured continuously across the full month. It does not describe the severity of an outage, the time needed to restore data or the business impact of a short outage during a critical transaction period.

Service credits may be inadequate compensation for regulatory penalties, lost revenue, notification costs or reputational damage. Customers should negotiate meaningful remedies for repeated or severe failure, including termination rights.

5. Audit Rights and Assurance Evidence

Audit rights allow a customer to assess whether contractual security obligations are being met. A useful audit clause may permit review of independent certifications, audit reports, penetration-test summaries, risk assessments, policies, incident records and relevant technical evidence.

The right should address:

  • reasonable notice and business-hour restrictions;
  • confidentiality and protection of other customers’ information;
  • auditor qualifications;
  • remote evidence review and on-site inspection;
  • frequency and triggers for audits;
  • treatment of urgent investigations;
  • allocation of reasonable costs; and
  • remediation of identified deficiencies.

A provider may offer a current independent assurance report instead of unrestricted customer audits. This can be efficient, but the report’s scope, period, exceptions and complementary customer controls must be examined. “Certified” does not mean “risk-free”; it means that an assessment was performed against a defined scope and criteria.

6. Data Location, Privacy and Cross-Border Processing

Data location affects privacy, government-access risk, regulatory compliance, litigation, evidence collection and operational resilience. A contract should identify where data is stored, processed, backed up and accessed by support personnel. It should also address metadata, logs, replicas, disaster-recovery copies and temporary caches.

The parties should establish:

  • the customer’s ownership or control of data;
  • processing only on documented instructions;
  • restrictions on secondary use and analytics;
  • assistance with access, correction, deletion and other data-subject rights;
  • breach and regulatory-notification assistance;
  • retention and deletion periods; and
  • lawful mechanisms for international transfers where required.

Data sovereignty is not identical to data residency. Residency concerns physical location; sovereignty concerns which laws and authorities may exercise control. A provider may store data in one country while allowing administration or legal access from another.

7. Subcontractors and Fourth-Party Risk

Providers often rely on data-centre operators, security-monitoring firms, support centres, payment processors and software suppliers. These entities create fourth-party risk. The primary provider should remain responsible for its subcontractors and should disclose relevant categories, locations and functions.

The contract should require advance notice of material subcontractor changes, customer objection rights where appropriate, equivalent security and privacy obligations, flow-down audit rights and incident cooperation. A customer should assess whether critical activities are concentrated in one subcontractor or region. Subcontracting is not itself unacceptable; undisclosed or uncontrolled subcontracting is the principal concern.

8. Confidentiality and Information Handling

A confidentiality clause should define confidential information broadly enough to include credentials, architecture, source code, security reports, personal data, business plans and incident information. It should specify permitted uses, authorised recipients, protective measures, compelled-disclosure procedures and the duration of obligations.

Some information, such as trade secrets or personal data, may require protection beyond the ordinary contractual term. The agreement should also address return or secure destruction, evidence preservation, handling of backups and disclosure to professional advisers or regulators.

9. Indemnities, Liability and Insurance

An indemnity is a promise by one party to compensate the other for specified losses, often including third-party claims. Cyber-related indemnities may cover intellectual-property infringement, confidentiality breaches, privacy violations, regulatory claims or provider negligence. The wording matters: an indemnity may be limited by notice requirements, control of defence, exclusions and liability caps.

A limitation-of-liability clause commonly contains:

  1. a general cap, such as fees paid during a defined period;
  2. exclusions of indirect or consequential loss; and
  3. higher caps or uncapped liability for defined matters.

Customers should examine whether the cap applies to data loss, security incidents, confidentiality breaches, privacy violations, gross negligence, wilful misconduct and indemnities. A low cap may be commercially disproportionate where the provider controls critical data or infrastructure.

Insurance does not replace security. Appropriate policies may include cyber liability, technology errors and omissions, professional indemnity, crime, general liability and business interruption cover. The customer should verify policy limits, exclusions, retroactive dates, notification duties and whether subcontractors are covered. Contractual insurance requirements should match the plausible scale of harm and the provider’s risk profile.

10. Vendor Due Diligence

Due diligence is a risk-based process, not a collection of documents. The customer should classify the service according to data sensitivity, operational criticality, regulatory impact, privilege level, concentration risk and substitutability.

A practical process is:

  1. Define the service and information flows. Identify data, users, interfaces, locations and dependencies.
  2. Classify impact. Consider confidentiality, integrity, availability, privacy and safety consequences.
  3. Collect evidence. Review assurance reports, certifications, policies, penetration-test summaries, incident history, financial information and references.
  4. Interview the provider. Test whether written claims reflect operational practice.
  5. Assess gaps. Record weaknesses, compensating controls, owners and deadlines.
  6. Negotiate the contract. Convert material requirements into enforceable terms.
  7. Approve or reject risk. Obtain documented acceptance from an authorised risk owner.
  8. Monitor continuously. Review changes, incidents, assurance reports, performance and subcontractors.

Evidence should be current and relevant. A three-year-old certificate, a report covering a different service, or a generic questionnaire may provide false assurance. Critical vendors should be reassessed periodically and when there is a major service, ownership, location or threat change.

11. Termination, Exit and Portability

Termination is often neglected until an outage, dispute or provider failure occurs. The contract should define termination for convenience, material breach, repeated SLA failure, insolvency, regulatory direction, security deterioration and unauthorised data use.

An exit plan should specify notice periods, transition assistance, data export formats, migration support, continued access, pricing during transition, deletion certificates, backup deletion and cooperation with a replacement provider. Portability depends on technical architecture as well as contract wording. Proprietary interfaces, undocumented dependencies and encrypted backups may make migration difficult even where the provider promises cooperation.

A customer should periodically test whether it can restore exported data and operate without the provider. Exit testing is especially important for identity services, security-monitoring platforms, backups and systems holding regulated records.

12. Ethical, Regulatory and Governance Considerations

Third-party governance involves more than protecting the customer’s interests. Organisations must consider the rights of employees, customers, data subjects and affected communities. Excessive monitoring by a service provider may violate privacy expectations. Automated analysis may introduce bias or make decisions without adequate explanation. Security information shared with a vendor should be limited to what is necessary.

Boards and senior managers remain accountable for material cyber risk even when operations are outsourced. Delegation of performance is not necessarily delegation of accountability. Records should show who approved the supplier, what risks were accepted and how ongoing oversight is performed.

Contracts should support applicable breach-notification duties, records-management obligations, sector regulations and lawful investigative access. They should not promise impossible compliance with every law worldwide. Instead, obligations should identify applicable jurisdictions, responsibilities, cooperation mechanisms and change-management procedures.

Applied Case: Meridian Health Cloud Migration

Background

Meridian Health, an illustrative regional healthcare organisation, moved its appointment and patient-portal systems to a cloud provider. The provider hosted production data in the organisation’s country but used an overseas support subcontractor. The contract promised “high availability” and “industry-standard security” but contained no precise RPO, no customer audit right and a liability cap equal to three months of subscription fees.

Problem

A compromised support credential was used to access administrative functions. Logs were retained for only seven days, and the provider initially notified Meridian after five days. Some backup copies were located in another jurisdiction. Meridian could not determine the extent of access quickly and faced regulatory investigation and patient concerns.

Analysis

The incident exposed several weaknesses:

  • privileged support access lacked sufficiently strong contractual controls;
  • subcontractor location and access were not transparent;
  • logging and retention were inadequate for investigation;
  • the notification trigger was unclear;
  • data-location provisions did not cover backup copies;
  • audit and evidence rights were weak; and
  • the liability cap did not reflect the sensitivity of health information.

Meridian also contributed to the risk by failing to require a documented shared-responsibility matrix and by not testing its incident escalation process.

Approach and solution

Meridian renegotiated the security schedule to require phishing-resistant authentication for privileged access, session logging, quarterly access review, minimum log retention, prompt incident notification and cooperation with regulators. The provider disclosed material subcontractors and agreed to flow down equivalent requirements. Meridian required defined RPO and RTO values, annual recovery tests, regional backup options and a structured exit plan. Liability and insurance were reviewed against the potential impact, and an independent assurance report was supplemented by targeted audit rights.

Outcome and learning points

The revised arrangement improved evidence availability, reduced uncertainty about responsibilities and gave Meridian practical remedies. The case demonstrates that security is produced by architecture, operations, governance and contract together. A contract cannot prevent every incident, but it can ensure that controls, information, cooperation and remedies exist when prevention fails.

Best-Practice Checklist

Before approving a cloud or managed-service contract, confirm that:

  • the service and data flows are documented;
  • responsibilities are assigned control by control;
  • security controls are specific and measurable;
  • SLA metrics, exclusions and remedies are clear;
  • incident notification and cooperation duties are defined;
  • audit evidence is relevant, current and accessible;
  • data and backup locations are known;
  • subcontractors are disclosed and controlled;
  • confidentiality, indemnity, liability and insurance are proportionate;
  • continuity, RPO, RTO and recovery testing are addressed;
  • termination, deletion and portability are practical; and
  • ongoing vendor monitoring has an accountable owner.

Challenges and Limitations

Contract negotiation can be difficult where a provider offers standard, non-negotiable terms. Smaller customers may have limited bargaining power and may need compensating technical controls, insurance or alternative providers. Assurance documents can be incomplete, and audits provide only a point-in-time view. Liability clauses may be uncertain under local law, while cross-border investigations can be slow. Finally, excessive contractual detail can create obligations that neither party measures or understands. Effective contracting therefore requires prioritisation, technical validation and continuous governance rather than reliance on legal wording alone.

Chapter Summary

Cloud and managed-service contracts allocate cyber risk among customers, providers and subcontractors. Effective agreements define the service, shared responsibilities, security controls, service levels, audit evidence, data locations, privacy duties, subcontracting controls and incident cooperation. RPO and RTO clarify recovery expectations, while availability percentages alone do not describe business impact. Confidentiality, indemnities, liability caps and insurance determine how loss is managed after failure. Vendor due diligence should be risk-based, evidence-driven and continuous. Finally, termination and portability provisions are essential because resilience includes the ability to leave a provider safely.

Key Terms

Cyber contract: An agreement containing technology, security and legal obligations.

Cloud computing: On-demand access to shared computing resources delivered over a network.

Managed service: An externally operated technology or security function.

Shared responsibility model: Allocation of security duties between provider and customer.

Service-level agreement: Contractual statement of measurable service performance.

Availability: The proportion of an agreed period during which a service is usable.

RPO: Maximum targeted age of data that may be lost after disruption.

RTO: Target time for restoring a service or function.

Audit right: Contractual permission to examine evidence of compliance.

Data residency: The physical location in which data is stored or processed.

Data sovereignty: Legal authority that may apply to data because of location, parties or access.

Subcontractor: A third party engaged by the primary provider.

Fourth-party risk: Risk arising from a supplier’s own suppliers.

Indemnity: A promise to compensate for specified losses or claims.

Liability cap: A contractual maximum for recoverable loss.

Due diligence: Structured investigation before accepting a supplier relationship.

Portability: Ability to move data or services to another environment.

Exit plan: Arrangements for transition, data return and secure termination.

Review Questions

5 Short Answer Questions

  1. What is meant by the shared responsibility model in cloud security?
  2. Distinguish between RPO and RTO.
  3. Why should subcontractors be disclosed in a cloud contract?
  4. What is the purpose of an audit right?
  5. Why is a service credit not always an adequate remedy for a cyber incident?

5 Long Answer Questions

  1. Explain the security clauses that should be included in a managed-service agreement.
  2. Discuss how data location and cross-border processing affect cyber governance.
  3. Analyse the relationship between indemnities, liability caps and cyber insurance.
  4. Describe a risk-based vendor due-diligence process.
  5. Explain why termination and portability should be designed before service commencement.

3 Analytical / Application Questions

  1. A provider offers 99.9% monthly availability but stores backups in an undisclosed country. Identify the contractual and governance questions that should be resolved before approval.
  2. A managed security provider refuses customer audits but supplies an independent assurance report. What factors should determine whether the alternative evidence is sufficient?
  3. Design a responsibility matrix for a cloud-hosted payroll system covering identity, encryption, logging, incident response, backup and data deletion.

Multiple Choice Questions with Answers

Question 1

Which document normally defines measurable uptime, response and restoration commitments?

A. Service-level agreement

B. Marketing brochure

C. Employee handbook

D. Source-code licence

Correct Answer: A. Service-level agreement

Question 2

An RPO primarily describes:

A. The maximum acceptable time to restore service

B. The maximum targeted age of recoverable data after disruption

C. The number of privileged administrators

D. The percentage of monthly uptime

Correct Answer: B. The maximum targeted age of recoverable data after disruption

Question 3

What is a major purpose of a contractual audit right?

A. To permit unlimited price increases

B. To replace all technical controls

C. To obtain evidence that security obligations are being met

D. To transfer all customer duties to the provider

Correct Answer: C. To obtain evidence that security obligations are being met

Question 4

Which statement best distinguishes residency from sovereignty?

A. Residency concerns physical location; sovereignty concerns applicable legal authority

B. Residency concerns passwords; sovereignty concerns availability

C. Residency applies only to paper records

D. There is no distinction

Correct Answer: A. Residency concerns physical location; sovereignty concerns applicable legal authority

Question 5

A provider’s subcontractor creates which type of risk for the customer?

A. Fourth-party risk

B. Arithmetic risk

C. Screen-resolution risk

D. Typography risk

Correct Answer: A. Fourth-party risk

Question 6

A 30-day month with 99.9% availability permits approximately how much unavailability?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 0.432 minutes

Correct Answer: B. 43.2 minutes

Question 7

Which is the strongest reason to include an exit plan?

A. To guarantee that no incident can occur

B. To make migration, data return and secure deletion practical

C. To remove the need for due diligence

D. To eliminate all service charges immediately

Correct Answer: B. To make migration, data return and secure deletion practical

Question 8

Which evidence is most useful in evaluating a provider’s security assurance?

A. An old, generic brochure

B. A current independent report covering the relevant service and scope

C. An unsigned verbal promise

D. A competitor’s website

Correct Answer: B. A current independent report covering the relevant service and scope

Question 9

What should a shared-responsibility matrix identify?

A. Only the provider’s marketing objectives

B. Control ownership, evidence and escalation responsibilities

C. Only the customer’s procurement budget

D. The personal preferences of administrators

Correct Answer: B. Control ownership, evidence and escalation responsibilities

Question 10

Why should liability caps be reviewed alongside insurance requirements?

A. Insurance determines the service’s user interface

B. The cap and insurance together affect recovery after loss

C. Liability caps automatically encrypt data

D. Insurance removes the need for incident response

Correct Answer: B. The cap and insurance together affect recovery after loss

Cyber Laws and Regulations
Chapter 13 of 15