Meridian Castings: Liability Package Accepted Too Easily

Halden / Meridian: Review of Clauses 1, 14 and Schedule 4

To: Partner | Re: Why the £2m cap is not the good news it looks like

I have not seen clause 11 in full, the Supplier Security Policy, the rest of Schedule 4 (including any Article 28 terms), or Halden's cyber policy. My conclusions are subject to those documents, and I flag below where they matter.

---

1. Memo for the partner

Bottom line. Do not approve clause 14 as drafted. The cap is mutual in form but the carve-outs make the exposure asymmetric. Halden's realistic liabilities, which are data and indemnity liabilities, sit entirely outside the £2m.

Where the exposure sits

1. 14.3(c) plus the "Data Obligations" definition create effectively unlimited liability for ordinary operations.

• The definition covers all obligations of either party on the handling, security, accuracy, storage or processing of any data, personal or not.
• Schedule 4 requires Halden to ensure all uploaded data is "accurate, complete, lawfully obtained and kept up to date". That is an absolute obligation.
• Halden's planners upload hand-compiled spreadsheets with a known 2–3% error rate. Halden would therefore be in breach, uncapped, from the first upload.
• The same carve-out covers "any applicable data protection law", so it catches even a technical breach.

2. The policy-incorporation mechanism lets Meridian expand Halden's uncapped liability unilaterally.

• "Data Obligations" includes any policy referred to in Schedule 4.
• Schedule 4 requires compliance with the Security Policy "as amended from time to time".
• Meridian can rewrite the Security Policy and thereby widen the uncapped category. This is the most dangerous drafting point and the easiest to miss.

3. Shared log-ins at Wolverhampton are probably a breach on day one.

• They almost certainly breach any sensible Security Policy and weaken Halden's position under UK GDPR Article 32.
• They also destroy the audit trail. In a breach dispute Meridian will say "your access controls failed", and Halden will struggle to prove otherwise.

4. 14.3(f) uncaps the clause 11 indemnity, and the indemnity runs one way.

• It covers third-party claims "arising from Halden's data", with no carve-back where Meridian's own act or default contributed.
• It also sits on top of 14.3(c) and (e), so the same event can be pleaded three ways.

5. 14.3 disapplies 14.2. The lead-in says "nothing in this Agreement limits or excludes" liability for these heads. Halden would therefore be liable for Meridian's indirect and consequential loss on every uncapped head. "Losses" is defined without any direct/indirect filter, so Meridian's lost profit, management time and reputational cost are arguably recoverable.

6. 14.3(e) (confidentiality) overlaps. Uploaded supplier and employee data will probably be "Confidential Information" as well, which creates a second uncapped route to the same loss.

7. 14.2 may hurt Halden as customer. If Meridian's platform fails, Halden's real losses (production disruption, expedited freight, stock-outs) risk being labelled indirect. Without express recoverable heads, the mutual exclusion benefits the supplier.

Magnitude. The broker's estimate for a serious breach affecting about 9,000 records is £1.5m–£6m. Halden's liability for that event is uncapped to Meridian, on top of Halden's own regulatory exposure. Halden's turnover is about £62m, and Halden has the deeper pocket in this relationship. That makes it the more attractive target.

Why the quick acceptance matters.

• The cap itself costs Meridian little, because the carve-outs remove the risks that matter.
• Meridian also dropped its hard-fought points on payment terms and term length straight after the cap call. A rational counterparty does that when it believes it has secured something more valuable. I read the carve-outs as that thing.
• Confirm whether the carve-outs came from Halden's draft or Meridian's mark-up. If they came from our own precedent, the position is easier to correct. If they came from Meridian, expect resistance.
• Nothing is agreed until the whole package is. Treat the cap call as a headline term only, and frame the carve-out discussion as completing the liability package, not re-trading.

Recommendation.

1. Delete 14.3(c), (e) and (f) in their present form.
2. Replace them with a separate, mutual, defined super-cap for personal-data losses, with listed recoverable heads.
3. Narrow "Data Obligations" and fix Schedule 4.
4. Remediate the access and data-quality practices before go-live. Contract drafting cannot cure a breach Halden knowingly commits.
5. Check that Halden's cyber cover responds to liability assumed under contract. Many policies exclude it.

Mutual super-cap and Meridian's covenant. A mutual super-cap also benefits Halden, because Meridian hosts the data and a Meridian-side breach is the likelier source of loss. Meridian has about £18m of revenue, so a high figure is only worth having if Meridian carries matching insurance. Ask for evidence of its cyber and tech E&O cover.

---

2. Questions for Halden's operations and IT leads

Data quality

1. Where do the 2–3% errors arise, and do any affect personal data fields? Could an error trigger automated ordering or payment, or does a human check it first?
2. Can uploads be validated through templates, controlled fields or an API in place of hand-compiled spreadsheets? Who owns correction once an error is found?

Access and security

3. How many shared log-ins are there, and for which users? Is there MFA or SSO? What is the joiner/leaver process?
4. Can individual credentials be in place before go-live? Is the Security Policy available now, and does Halden meet it today?

Data scope and lawfulness

5. Which fields are in the 9,000 records? Look for bank details, home addresses, personal emails, HR or health data, and sole-trader suppliers.
6. What is the lawful basis, and have privacy notices been updated for this processing? Has a DPIA been done?
7. Do supplier contracts restrict sharing supplier data with third parties? That bears on "lawfully obtained".
8. Where will Meridian host the data? Who are its sub-processors, and are there any transfers outside the UK?

Insurance and incident handling

9. What are the cyber policy limits and retention? Does it cover liability assumed under contract and regulatory costs? Are there notification conditions?
10. What is Halden's incident-response process? Who liaises with Meridian, and what is the exit and deletion plan?

---

3. Proposed replacement wording

Clause 1 (new or amended definitions)

> "Data Protection Law" means the UK GDPR, the Data Protection Act 2018 and all other applicable law relating to the processing of personal data. > > "Data Protection Breach" means a party's breach of Data Protection Law or of Part B (Personal Data) of Schedule 4. > > "Data Protection Losses" means the following, to the extent reasonably and properly incurred and caused by a Data Protection Breach: (a) investigation, forensic, containment and remediation costs; (b) the costs of notifying regulators and affected individuals and of providing 12 months' credit monitoring; (c) sums paid to data subjects by way of compensation; (d) regulatory fines and penalties, to the extent lawfully recoverable; and (e) reasonable legal costs. > > "Data Obligations" means the obligations in Part B (Personal Data) of Schedule 4 only. *[Delete the reference to "any service description or policy".]* > > "Losses" means direct losses, liabilities, costs and expenses properly incurred, subject to clause 14.

Clause 14

> 14.1 Subject to clauses 14.3, 14.4 and 14.5, each party's total aggregate liability arising under or in connection with this Agreement, whether in contract, tort (including negligence) or otherwise, shall not exceed £2,000,000. > > 14.2 Subject to clause 14.3, neither party shall be liable for loss of profit, loss of goodwill, or indirect or consequential loss. The following are recoverable as direct losses: costs of restoring lost or corrupted data; reasonable additional operating or procurement costs and the cost of replacement services; wasted expenditure; and Data Protection Losses. > > 14.3 Nothing in this Agreement limits or excludes liability for: (a) death or personal injury caused by negligence; (b) fraud or fraudulent misrepresentation; or (c) any liability that cannot be limited or excluded by law. > > 14.4 Each party's total aggregate liability for Data Protection Losses, and for breach of clause 9 to the extent it concerns personal data, shall not exceed [£4,000,000] (the "Data Cap"). Sums counted towards the Data Cap do not erode the cap in clause 14.1, and vice versa. > > 14.5 The Customer's liability under clause 11 is limited to third-party claims that the Customer Data, as supplied by the Customer, infringes third-party rights or was supplied in breach of law. It does not apply to the extent the claim is caused or contributed to by the Supplier's breach, negligence or processing otherwise than on the Customer's documented instructions. Liability under clause 11 is subject to the Data Cap where it relates to personal data, and otherwise to clause 14.1. *[Add a reciprocal Supplier IP indemnity, with an agreed cap.]* > > 14.6 No amendment to any policy, service description or other document referred to in this Agreement shall extend or alter either party's liability under this Agreement.

Schedule 4 (key fixes)

> The Customer shall use reasonable skill and care to ensure that Customer Data is materially accurate and complete when uploaded and has been lawfully obtained, and shall correct errors promptly after becoming aware of them. The Supplier shall provide reasonable validation functionality. Errors within [tolerance to be agreed] are not a breach. > > The Customer shall maintain access controls meeting the Security Requirements at Annex A. The Supplier may amend those requirements only by written notice of at least 60 days, and any amendment that materially increases the Customer's cost or effort is subject to the Change Control Procedure. The Supplier shall not reduce the security of its own systems.

Notes on the wording

• The Data Cap is additive to the general cap. That gives Halden more recovery against Meridian but a higher ceiling on its own exposure, so the figure needs sign-off against Halden's insurance.
• On personal-data heads, I would settle at no more than the broker's top-of-range figure and no more than the insurable limit.

---

4. Next call: what to trade and what to hold

Hold firm

1. The removal of uncapped liability for data accuracy and non-personal data. No "Data Obligations" definition that incorporates policies.
2. No unilateral policy changes that can affect liability (14.6 and the Schedule 4 notice mechanism).
3. Deletion of the blanket 14.3(f) carve-out and a narrowed clause 11 indemnity with a Meridian-fault carve-back.
4. The principle that 14.2 is not disapplied for data heads, with defined recoverable losses.
5. A mutual, defined super-cap, never uncapped, and set within Halden's insurance.

Trade

1. Super-cap level. Open at £4m and move to £5m if the insurer confirms cover. Do not go beyond that.
2. Charges. Offer that Halden's obligation to pay the Charges sits outside the cap. It costs Halden nothing, because it would pay them anyway.
3. Confidentiality. Accept an uncapped or higher cap for deliberate breach of confidentiality in non-personal-data commercial information.
4. Operational commitments. Offer individual log-ins and MFA by a go-live date, annual security attestation, and a reasonable audit right. These are cheap to give and are also what we should be doing anyway.
5. Indemnity scope. Accept a narrow Halden indemnity for third-party IP or lawfulness claims over the data, at the super-cap.
6. Payment terms and term length. Meridian valued these enough to push hard. Do not reopen them, but keep them in reserve as currency if Meridian resists on carve-outs.

Tactics

• Welcome the cap acceptance, then say plainly that the package is not agreed until the carve-outs are settled.
• Do not volunteer details of Halden's data-quality or access practices, and do not give warranties about them. Fix them internally before signing.
• Ask for Meridian's insurance details at the same time.

Meridian Castings: Clause 14, Clause 1 and Schedule 4 Review

1. Review Memo

To: [Partner] From: [Associate] Re: Halden / Meridian, limitation of liability. The £2m cap does not protect Halden.

Summary

Meridian agreed our £2m mutual cap quickly. As drafted, though, the cap does not cover the liabilities Halden is most likely to incur.

• The carve-outs remove Halden's real exposure from the cap. Clause 14.3(c), (e) and (f) leave uncapped any breach of Schedule 4, any breach of data protection law, any breach of confidentiality and any indemnity.
• Those heads are where Halden's risk sits. Halden is the data uploader, the controller and the only party giving an indemnity.
• The consequential loss exclusion falls away too. Clause 14.3 says "nothing in this Agreement limits or excludes" liability under the carve-outs. So 14.2 does not apply to them either. Halden's exposure under those heads is both uncapped and includes indirect loss.
• Meridian's behaviour fits this reading. It conceded payment terms and term length straight after the cap call. I read that as a party that knew the cap cost it little. Meridian's own likely liability to Halden (service failure) is already narrowed by 14.2 and probably by service credits, which we need to check. Meanwhile it has uncapped recourse against Halden.

Where the exposure sits

1. Accuracy (Schedule 4). Halden "shall ensure all data uploaded is accurate, complete … and kept up to date." This is an absolute obligation. Halden's planners work from hand-compiled spreadsheets with a known 2–3% error rate, so Halden will be in breach from the first upload.

• The definition of "Data Obligations" covers data "whether personal or not". A wrong supplier lead time is therefore an uncapped breach under 14.3(c).
• The definition is capitalised and 14.3(c) is not. That needs to be fixed either way. If the defined term is applied, it also pulls in "any service description or policy referred to in it."

2. Access controls (Schedule 4). Halden must comply with Meridian's Security Policy "as amended from time to time". Meridian can change that policy on its own, and so change the scope of Halden's uncapped liability without Halden's agreement.

• Shared log-ins on the Wolverhampton planning floor will almost certainly breach any credible security policy.
• They are also likely to breach the licence terms if access is licensed per named user. That is a separate exposure (an under-licensing claim) which sits inside the cap but should be checked.

3. Data protection law (14.3(c)). Halden is the controller of about 9,000 supplier-contact and employee records and carries most of the UK GDPR duties. Meridian, as processor, has a much narrower set of direct obligations.

• "Mutual" uncapped liability for data protection breach therefore falls mainly on Halden.
• The broker's estimate for a serious breach is £1.5m–£6m. That is up to three times the cap and nearly eight times the contract value.
• The extract of Schedule 4 contains no Article 28 processor terms binding Meridian. If none exist elsewhere, Halden as controller is itself in breach of Article 28(3).

4. Indemnity (clause 11 and 14.3(f)). Halden indemnifies Meridian, without limit, for third-party claims "arising from Halden's data". This is a one-way indemnity.

• There is no requirement that Halden was at fault, no carve-out where Meridian caused the loss, and no conduct-of-claims or mitigation provisions.
• "Losses" means "all losses", so indirect loss is in scope.
• A single data incident could trigger a Schedule 4 breach, a data protection breach and the indemnity at the same time, each one uncapped.

5. Confidentiality (14.3(e)). If shared credentials are used by agency or contract staff, that may amount to disclosure of Meridian's platform and confidential information. Again this is uncapped.

6. Insurance gap. Cyber and liability policies commonly exclude liability assumed under contract beyond what would arise at law. Uncapped indemnities and absolute accuracy warranties may well be uninsured. We need the broker's confirmation before any figure is agreed.

Does the mutual uncapped position help Halden?

Partly. Meridian's own data breaches are uncapped as well, and we give some of that up if we introduce a super-cap. On balance the trade is clearly in Halden's favour, for two reasons:

• Likelihood. Halden's breach is close to certain on the current drafting. Meridian's is contingent.
• Ability to pay. An uncapped claim against an £18m-revenue supplier is only worth what its balance sheet and insurance will meet. We should ask for Meridian's insurance certificate.

Recommendation

Do not sign off clause 14 as drafted. We should present the fix as making the agreed cap work, not as reopening it. The proposed changes are:

• Delete 14.3(c), (e) and (f).
• Put data protection, confidentiality and indemnity liability under a defined, mutual data super-cap sized to Halden's insurance.
• Make the accuracy obligation reasonable-endeavours.
• Freeze the Security Policy at the signing version.
• Narrow and cap the indemnity, and add a contributory-cause reduction.
• Require Article 28 terms from Meridian.

Before the next call, we also need to review clause 11 in full, the service levels and any credits-as-sole-remedy wording, and the termination and exit provisions.

2. Questions for Halden's Operations and IT Leads

Data content and minimisation

1. Which employee data fields are uploaded, and why does an inventory service need them at all? Is any of it HR, absence or other special category data? If the employee data can be removed, the exposure drops significantly.
2. How are the supplier spreadsheets compiled and checked? Can a validation step, or Meridian's own import validation, bring the 2–3% error rate down? Who corrects errors once found, and how quickly?
3. What decisions are made on the platform's output, such as reorder triggers and supplier commitments? Could an input error cause a loss to a third party, such as a supplier or customer?

Access and security

4. How many shared log-ins are in use, who uses them (including agency and contract staff), and can Halden move to named accounts with SSO and MFA before go-live? What would that cost, and how is the service licensed?
5. Has anyone seen Meridian's current Security Policy? Can Halden comply with it today? Who would monitor changes to it?
6. Has Halden had any data incident in the last three years? Does it have an incident response plan that meets the 72-hour ICO notification deadline?

Hosting, processing and exit

7. Where will Meridian host the data, which sub-processors does it use, and is any data transferred outside the UK?
8. How will data be returned or deleted on exit?

Business impact and insurance

9. If the platform fails, what is the realistic loss: line stoppage, expediting costs, missed deliveries? This tells us whether £2m against Meridian is adequate and how much the consequential loss exclusion hurts Halden as claimant.
10. For the broker:

• What is Halden's cyber policy limit and excess?
• Does the policy cover contractually assumed liability and indemnities?
• Does it cover notification, remediation and regulatory defence costs?

3. Proposed Replacement Wording

Clause 1: replace "Data Obligations"

> "Data Protection Obligations" means each party's obligations under Schedule 4 and under Data Protection Legislation, in each case to the extent relating to Personal Data. > > "Data Quality Obligations" means the Customer's obligations under paragraph 1 of Schedule 4. > > "Security Policy" means the Supplier's security policy version [x] dated [ ] in the form annexed at Annex A to Schedule 4, as varied only in accordance with paragraph 3 of Schedule 4.

Clause 14

> 14.1 Subject to clauses 14.3 and 14.4, each party's total aggregate liability arising under or in connection with this Agreement, whether in contract, tort (including negligence), breach of statutory duty or otherwise, shall not exceed £2,000,000 (the "General Cap"). > > 14.2 Subject to clause 14.3, neither party shall be liable for any indirect or consequential loss. The following shall be treated as direct losses recoverable subject to clauses 14.1 and 14.4: (a) reasonable costs of notifying data subjects and regulators; (b) reasonable costs of investigating, remediating and restoring data; and (c) regulatory fines and penalties, to the extent recovery is permitted by law. > > 14.3 Nothing in this Agreement limits or excludes liability for: (a) death or personal injury caused by negligence; (b) fraud or fraudulent misrepresentation; or (c) any other liability which cannot lawfully be limited or excluded. > > 14.4 Subject to clause 14.3, each party's total aggregate liability in respect of: (a) breach of the Data Protection Obligations; (b) breach of clause 9 (Confidentiality); and (c) any indemnity under this Agreement, shall not exceed £[3,000,000] (the "Data Cap"). Liability under this clause 14.4 shall not count towards the General Cap. Liability for breach of the Data Quality Obligations falls within the General Cap only. > > 14.5 Each party's liability shall be reduced to the extent that the relevant loss was caused or contributed to by the other party's breach of this Agreement, negligence or failure to comply with the Security Policy or Data Protection Legislation.

Schedule 4

> 1. The Customer shall use reasonable endeavours to ensure that Customer Data is accurate and complete in all material respects when uploaded, and shall correct any material error of which it becomes aware without undue delay. The Supplier acknowledges that Customer Data is compiled in part from third-party sources and may contain errors. The Customer gives no warranty as to the accuracy of third-party-sourced data. The Supplier's sole remedy for inaccurate Customer Data that is not Personal Data shall be correction by the Customer and relief from the Service Levels to the extent affected. > > 2. As controller, the Customer shall ensure that it has a lawful basis for the processing of Personal Data contemplated by this Agreement and has provided all required privacy information. > > 3. The Customer shall maintain access controls in accordance with the Security Policy. The Supplier may propose changes to the Security Policy on not less than 60 days' written notice. Any change that materially increases the Customer's obligations or costs shall take effect only if agreed through the Change Control Procedure. > > 4. [Insert full Article 28 UK GDPR processor obligations binding the Supplier: processing on documented instructions, confidentiality of personnel, security measures, sub-processor approval, assistance, breach notification within [24/48] hours, deletion or return on exit, and audit rights.]

Clause 11: indemnity wording

> The Customer shall indemnify the Supplier against Losses arising from third-party claims to the extent that they result from (a) Customer Data having been obtained by the Customer in breach of Data Protection Legislation, or (b) Customer Data infringing a third party's intellectual property rights. The indemnity excludes Losses to the extent caused by the Supplier's breach, negligence or wilful default. It is subject to: prompt notice of the claim; the Customer having conduct of the claim; no admission by the Supplier without the Customer's consent; the Supplier's duty to mitigate; and clauses 14.2 and 14.4.

4. Next Call: Trade and Hold

Framing. Present all of this as giving effect to the cap Meridian has already agreed. As drafted, the carve-outs mean the agreed cap does not operate for the foreseeable claims. Do not tell Meridian we have read its quick concession as a sign of anything. Open on the Data Cap at £3m.

Hold firm on:

• Deleting 14.3(c), (e) and (f). No uncapped data, confidentiality or indemnity liability for Halden.
• Reasonable-endeavours accuracy, with inaccurate non-personal data falling outside the Data Cap.
• Freezing the Security Policy at the signing version, with changes only through change control.
• Narrowing and capping the indemnity, with conduct-of-claims provisions and the 14.5 contributory reduction.
• Article 28 processor terms binding Meridian. This is a legal requirement for Halden, not a negotiating point.
• Applying 14.2 to the carve-out heads.

Willing to trade:

• The Data Cap figure. Move from £3m up to £4–5m, but no higher than Halden's confirmed insured limit.
• The structure of the Data Cap. Accept it as additional to the General Cap rather than inclusive of it.
• A mutual uncapped carve-out for deliberate wrongdoing. Accept this if narrowly defined as deliberate unlawful disclosure or wilful abandonment. It also protects Halden.
• Fees. Accept that fees payable are outside the cap.
• Halden security commitments. Offer an operational undertaking to move to named-user log-ins with MFA by a fixed date, such as go-live plus 60 days. Meridian's concern there is real and cheap to meet.
• A moderate reduction in the General Cap, for example to the greater of £1.5m and 150% of fees paid. Only do this if the operations answers show limited loss from service failure.
• One of the payment or term points Meridian dropped, for example annual in advance with a shorter payment window. These points have value to Meridian and cost Halden little.

Walk-away point. If Meridian insists on uncapped exposure for Halden for accuracy or for the indemnity, recommend that Halden does not sign until its insurance position has been confirmed in writing.

1. Review memo for partner — Clause 14 / Definitions / Schedule 4

To: Partner Re: Halden / Meridian — limitation of liability Summary: I would not sign off the £2m cap as drafted. Meridian’s quick acceptance is explained by the carve-outs: the main risks for Halden sit outside the cap entirely.

Key point

Clause 14.1 gives a mutual £2m aggregate cap, but clause 14.3 removes from that cap the very liabilities most likely to arise for Halden:

• breach of “Data Obligations” or data protection law — uncapped;
• confidentiality breach — uncapped;
• any indemnity — uncapped, including the clause 11 indemnity in favour of Meridian for third-party claims arising from Halden’s data.

Given Halden’s operational facts — manual spreadsheet uploads, known 2–3% error rates, shared log-ins and c.9,000 supplier-contact / employee records — the real exposure is not the ordinary SaaS fee dispute. It is a data-quality, access-control, personal data or indemnity claim. Those are currently uncapped.

Why Meridian likely accepted the £2m cap quickly

The accepted cap is largely cosmetic from Halden’s perspective. The drafting lets Meridian say the headline cap is agreed while preserving uncapped recovery for:

1. bad or inaccurate customer data;
2. unlawful or non-compliant personal data uploads;
3. failure to comply with Meridian’s security policy, including as amended later;
4. confidentiality breaches;
5. the customer indemnity.

That is a better position for Meridian than a clean £2m mutual cap.

Specific problem areas

1. “Data Obligations” is too broad. The definition captures all obligations relating to “handling, security, accuracy, storage or processing” of any data, personal or non-personal, including service descriptions and policies. This means a non-personal inventory data error could become an uncapped claim if framed as a breach of data accuracy obligations.

2. Schedule 4 imposes an absolute warranty. “Customer shall ensure all data uploaded is accurate, complete, lawfully obtained and kept up to date” is absolute. Halden already knows there is a 2–3% manual error rate. That is a known breach risk from day one unless operationally fixed or qualified.

3. Dynamic security policy is dangerous. Halden must comply with Meridian’s Security Policy “as amended from time to time”. If non-compliance is uncapped, Meridian can materially change the obligations post-signature and expose Halden to uncapped liability.

4. Shared log-ins are a current breach risk. If the Security Policy requires individual credentials, MFA or auditability, Halden may be in immediate breach. Shared log-ins also make causation and fault difficult if there is an incident.

5. Clause 11 indemnity is uncapped. The indemnity for third-party claims arising from Halden’s data is potentially the largest customer-side exposure. “Arising from” is broad and may catch Meridian customer/supplier claims, data subject claims, regulatory response costs, legal costs and remediation costs, depending on how “Losses” is used. It should at least be fault-based, subject to conduct/mitigation protections, and capped.

6. Data protection exposure benchmark exceeds cap. The broker’s estimate for a serious breach affecting 9,000 records is £1.5m–£6m. That supports a separate negotiated data/privacy super-cap, not an uncapped carve-out. It also suggests checking available insurance before agreeing any number.

Recommended position

Do not approve the current clause. We should:

• keep the £2m general cap;
• delete the uncapped carve-outs for data obligations, confidentiality and indemnities;
• replace them with a defined, inclusive super-cap;
• narrow Schedule 4 from an absolute data accuracy warranty to a reasonable controls / materially accurate standard;
• freeze or control amendments to Meridian’s Security Policy;
• cap the clause 11 indemnity and narrow it to third-party claims caused by Halden’s breach, not merely claims “arising from” Halden data.

My preferred commercial position is:

• Halden general liability cap: £2m;
• Halden data / confidentiality / indemnity super-cap: £3m aggregate, inclusive of the general cap;
• Meridian security / data protection / confidentiality super-cap: ideally £5m, or at least matched to its cyber/E&O insurance, because Meridian controls the platform and security environment.

If Meridian insists on formal mutuality, use a mutual £3m super-cap for data protection, confidentiality and indemnity claims, but only after narrowing the underlying obligations.

---

2. Questions for Halden operations and IT before signing

Operations

1. What categories of data will be uploaded — supplier contacts only, employee data, pricing, forecasts, purchase history, special category data?
2. Who compiles the spreadsheets and what checks are performed before upload?
3. Is the 2–3% error rate measured, estimated or anecdotal? What types of errors occur?
4. Could inaccurate data cause third-party loss — e.g. missed supplier orders, incorrect stock levels, production downtime or customer delivery failures?
5. Can Halden implement a data validation / approval process before upload? If so, when?
6. Is all supplier and employee data lawfully collected and covered by existing privacy notices / supplier terms?
7. How often will uploaded data be refreshed? Who owns keeping it up to date?
8. Are there legacy records that may be inaccurate or stale at the point of migration?

IT / Security

1. What does Meridian’s current Security Policy require? Has anyone reviewed it against current practice?
2. Can Halden stop shared log-ins before go-live? If not, what transition period is required?
3. Does the platform support individual user accounts, role-based access, MFA, SSO and audit logs?
4. Who will administer user access and remove leavers?
5. Will Meridian process personal data as processor, independent controller or joint controller? Is there a separate data processing agreement?
6. Where is data hosted and are there international transfers / sub-processors?
7. What cyber / tech E&O insurance does Halden carry, and does it respond to contractual indemnities, data breach costs and regulatory investigations?
8. Has Halden had any prior data incidents, access-control failures or audit findings relevant to this service?

---

3. Proposed replacement wording

A. Replace clause 14.3 and add super-cap

```text 14.3 Nothing in this Agreement limits or excludes either party’s liability for: (a) death or personal injury caused by negligence; (b) fraud or fraudulent misrepresentation; or (c) any liability which cannot lawfully be limited or excluded.

14.4 Subject to clause 14.3, each party’s total aggregate liability arising under or in connection with: (a) breach of Data Protection Legislation; (b) breach of the data security obligations expressly set out in Schedule 4; (c) breach of clause 9 (Confidentiality); and (d) any indemnity given under this Agreement, shall not exceed £3,000,000 in aggregate.

14.5 The cap in clause 14.4 is inclusive of, and not in addition to, the cap in clause 14.1. Amounts recovered under clause 14.1 shall count towards the cap in clause 14.4 and vice versa.

14.6 For the avoidance of doubt, breach of an obligation relating to the accuracy, completeness or updating of non-personal operational or inventory data shall be subject to the cap in clause 14.1 and shall not fall within clause 14.4 unless and to the extent the claim also arises from a breach of Data Protection Legislation or the data security obligations expressly set out in Schedule 4. ```

If we can secure an asymmetric position, I would adjust clause 14.4 as follows:

```text 14.4 Subject to clause 14.3: (a) the Customer’s total aggregate liability for the matters listed in clauses 14.4(a) to 14.4(d) shall not exceed £3,000,000; and (b) the Supplier’s total aggregate liability for breach of Data Protection Legislation, data security obligations, confidentiality obligations, or any indemnity relating to infringement, data loss, unauthorised access or security breach shall not exceed £5,000,000. ```

B. Narrow definition of “Data Obligations”

```text "Data Obligations" means the obligations expressly set out in Schedule 4 relating to the lawful provision of Personal Data, access controls and security measures, and data accuracy. Data Obligations do not include obligations contained in any policy, service description or other document as amended after the Effective Date unless the relevant amendment has been notified to the Customer in writing, is reasonable, does not materially increase the Customer’s cost or risk, and the Customer has been given a reasonable period to comply. ```

C. Amend Schedule 4

```text Customer shall use reasonable endeavours and maintain reasonable internal controls to ensure that data uploaded by or on behalf of Customer is, so far as within Customer’s knowledge and control, materially accurate, complete, lawfully obtained and kept reasonably up to date.

Customer shall not knowingly upload data which is materially inaccurate, unlawfully obtained or misleading.

Customer shall maintain access controls to the platform in accordance with the Supplier’s Security Policy as provided to Customer before the Effective Date, provided that: (a) Supplier shall give Customer reasonable prior written notice of any amendment; (b) Customer shall have a reasonable period to comply with any amendment; (c) no amendment shall materially increase Customer’s obligations, cost or liability without Customer’s prior written agreement; and (d) Customer shall not be liable for failure to comply with any amended requirement before the end of the applicable compliance period.

Customer shall ensure that, from [go-live / date], individual user credentials are used for access to the platform and that shared log-ins are not used, except with Supplier’s prior written approval during any agreed transition period. ```

D. Narrow the customer indemnity

If clause 11 remains, I would amend it along these lines:

```text Customer shall indemnify Supplier against Losses finally awarded by a court of competent jurisdiction, or agreed in settlement with Customer’s prior written consent, arising from a third-party claim to the extent caused by Customer’s breach of Data Protection Legislation or Customer’s knowing upload of data which it was not entitled to provide to Supplier.

The indemnity shall not apply to the extent the claim arises from: (a) Supplier’s breach of this Agreement; (b) Supplier’s breach of Data Protection Legislation; (c) Supplier’s failure to comply with its security obligations; (d) Supplier’s processing of Customer Data other than in accordance with this Agreement or Customer’s documented instructions; or (e) Supplier’s failure to mitigate.

Supplier shall promptly notify Customer of any claim, allow Customer reasonable conduct of the defence and settlement, and provide reasonable assistance. This indemnity is subject to the liability caps in clause 14. ```

---

4. Next call — what to trade and what to hold firm on

Trade

• Accept a specific data/privacy/confidentiality super-cap above £2m, provided it is not uncapped.
• Accept a customer indemnity for third-party claims genuinely caused by Halden’s unlawful data or breach of data protection law.
• Accept a commitment to end shared log-ins, but with a realistic implementation period.
• Accept compliance with Meridian’s security policy if the current version is disclosed and future amendments are controlled.
• If commercially necessary, accept a mutual £3m super-cap rather than asymmetric caps.

Hold firm

• No uncapped liability for “Data Obligations” as currently defined.
• No uncapped customer indemnity.
• No absolute warranty that all uploaded data is accurate, complete and always up to date.
• No uncapped exposure to Meridian policies amended unilaterally after signing.
• No indemnity for claims merely “arising from” Halden data regardless of Meridian fault.
• No carve-out that treats non-personal operational data errors as uncapped data breaches.

MEMORANDUM

To: [Partner Name] From: [Senior Counsel] Date: October 26, 2023 Subject: Halden Components Ltd / Meridian Castings – Limitation of Liability Review

You mentioned Meridian accepted our £2m mutual cap on the first call without pushback. Having reviewed the liability package against Halden’s operational realities, I can see why. The £2m cap is an illusion for our client. Meridian conceded the general cap because they have masterfully carved out all of Halden’s actual, foreseeable operational risks, rendering our liability virtually unlimited.

Here is where our real exposure sits:

1. The "Data Obligations" Trojan Horse (Clauses 14.3(c) + Schedule 4 + Definitions) Meridian has drafted the definition of "Data Obligations" to include the *accuracy* and *security* of *any* data (not just personal data).

• The Accuracy Trap: Under Schedule 4, Halden must ensure all uploaded data is "accurate [and] complete". We know Operations manually compiles spreadsheets with a 2-3% error rate. Every single upload will technically breach Schedule 4. Because Clause 14.3(c) carves "Data Obligations" out of the cap, Halden will have uncapped liability for any losses Meridian suffers due to these routine data errors (e.g., bad analytics leading to third-party claims).
• The Security Trap: Schedule 4 requires Halden to maintain access controls in accordance with Meridian's Security Policy, which Meridian can amend "from time to time." Our Wolverhampton floor uses shared log-ins. This almost certainly breaches standard IT security policies. Again, a breach here bypasses the £2m cap entirely via 14.3(c).

2. The Uncapped Indemnity (Clauses 11 + 14.3(f)) Clause 11 gives Meridian an indemnity for third-party claims arising from Halden's data. Clause 14.3(f) leaves all indemnities uncapped. If Halden's 2-3% inaccurate data causes Meridian to face a claim from one of its downstream users or partners, Halden is on the hook for unlimited indemnity payouts.

3. The Confidentiality Backdoor (Clause 14.3(e)) Confidentiality breaches are entirely uncapped. In the event of a data breach (e.g., resulting from the Wolverhampton shared log-ins), Meridian will likely frame the loss of employee/supplier data as a breach of confidentiality to bypass the general cap, exposing us to the broker’s £1.5m–£6m estimated remediation costs without the protection of the £2m cap.

In short, Meridian didn't fight the £2m cap because it applies to almost nothing Halden will actually do wrong. We need to restructure this clause to reflect our operational reality.

QUESTIONS FOR HALDEN'S OPERATIONS & IT LEADS

Before we revert to Meridian, please confirm the following with the client teams:

For IT:

1. Have you reviewed Meridian’s *current* Security Policy, and are we currently compliant?
2. Can we eliminate the shared log-ins on the Wolverhampton planning floor immediately? If not, what is the timeline to move to individual authentication?
3. Can we implement an automated API or validation tool to bypass manual spreadsheet uploads and reduce the 2-3% error rate?

For Operations / Commercial:

1. What exactly does Meridian do with our supplier/employee data? If our data is 3% inaccurate, who specifically is financially harmed by that, and how?
2. Are you comfortable with Meridian having the right to unilaterally change their Security Policy, or do we need to freeze the policy to the version provided at signing?

PROPOSED REPLACEMENT WORDING (CARVE-OUTS & SUPER-CAP)

*Drafting Note: We must delete data, confidentiality, and indemnities from the unlimited list in 14.3 and move them into a newly created "Super-Cap" in 14.4. I have set the Super-Cap at £5m to align with the upper end of the broker's exposure estimate (£1.5m–£6m).*

Amend Clause 14.3 as follows: "14.3 Nothing in this Agreement limits or excludes liability for: (a) death or personal injury caused by negligence; (b) fraud or fraudulent misrepresentation; ~~(c) breach of the data obligations in Schedule 4 or of any applicable data protection law;~~ (c) ~~(d)~~ any liability that cannot be limited by law. ~~(e) breach of clause 9 (Confidentiality); (f) any indemnity given under this Agreement.~~"

Insert new Clause 14.4 (Super-Cap): "14.4 Notwithstanding Clause 14.1, each party's total aggregate liability arising under or in connection with this Agreement in respect of: (a) breach of Clause 9 (Confidentiality); (b) breach of any applicable data protection laws or the Data Obligations in Schedule 4; and (c) any indemnity given under this Agreement, shall not exceed £5,000,000."

*(Note: We also need to amend Schedule 4 to require "commercially reasonable efforts" regarding data accuracy, rather than absolute accuracy, but capping the exposure is the primary safeguard.)*

NEGOTIATION STRATEGY: THE NEXT CALL

What to Hold Firm On:

• Capping Data/Confidentiality/Indemnities: This is non-negotiable. We cannot accept unlimited liability for operational processes (spreadsheet uploads and shared log-ins) that are already known to be imperfect. The £5m super-cap provides them with ample commercial protection (more than 6x the contract value) and covers the broker's worst-case scenario.
• Diluting Schedule 4: We must hold firm on changing "Customer shall ensure all data uploaded is accurate" to "Customer shall use commercially reasonable efforts to ensure material accuracy..." We cannot sign up for an absolute warranty on hand-compiled data.
• Security Policy Changes: We must hold firm that Halden is only bound by Meridian's Security Policy *as provided at the Effective Date*. Meridian cannot be allowed to unilaterally amend security requirements (potentially making shared log-ins a material breach overnight) without our agreement.

What to Trade:

• The General Cap: If Meridian complains that £5m isn't enough for the super-cap, or if they balk at our changes to 14.3, we can offer to raise the general cap in 14.1 from £2m to £2.5m or £3m. As the customer paying £780k, our risk of causing a £3m general contract breach (unrelated to data/indemnities) is incredibly low, so giving ground here costs us very little.
• Payment Terms: Meridian previously pushed hard for favorable payment terms (currently annual in advance). If they get aggressive on the liability caps, we can confirm we will not challenge the "annual in advance" payment structure, using our concession there to buy their acceptance of the super-cap.

1. REVIEW MEMORANDUM

TO: Commercial Practice Head / Lead Partner FROM: Senior Commercial & Technology Associate DATE: 24 October 2023 SUBJECT: Halden Components Ltd / Meridian Castings Software Ltd – Analysis of Liability Architecture and Latent Risk

---

1. EXECUTIVE SUMMARY: THE "EASY" CAP IS A CONCESSION TRAP Meridian’s immediate acceptance of Halden’s £2,000,000 aggregate liability cap without a counter-offer is an immediate commercial red flag. The cap is largely an optical concession.

By cross-referencing Clause 14.1 with the carve-outs in Clause 14.3, the definition of "Data Obligations" in Clause 1, and the operational warranties in Schedule 4, Halden has inadvertently negotiated a position where:

1. Meridian’s core operational failure (e.g., platform outage, erroneous analytics causing line shutdowns) is safely insulated behind the £2,000,000 aggregate cap and the Clause 14.2 consequential loss waiver; while
2. Halden’s actual operational footprint (erroneous inventory inputs, shared shop-floor credentials, supplier data transfers) is completely uncapped via Clauses 14.3(c), 14.3(e), and 14.3(f).

Halden’s estimated catastrophic exposure on its 9,000 records sits between £1.5m and £6m. Under the current draft, Halden faces unlimited liability precisely where its operational vulnerabilities are highest.

---

2. WHERE THE REAL EXPOSURE SITS

``` ┌────────────────────────────────────────────────────────┐ │ Clause 14.1 Mutual Cap (£2,000,000) │ └───────────────────────────┬────────────────────────────┘ │ Carve-Outs Under 14.3 ┌───────────────────────────────┼──────────────────────────────┐ ▼ ▼ ▼ Clause 14.3(c) Clause 14.3(f) Clause 14.3(e) "Data Obligations" & "Any Indemnity Given" "Breach of Clause 9" Data Protection Breaches (Includes Cl. 11 Data Ind.) (Confidentiality) │ │ │ ├─ Schedule 4: Strict └─ Meridian passes through └─ Data incidents │ warranty of "accuracy" all 3rd-party claims often double-pled │ (Halden has 2-3% error rate) uncapped to Halden as Cl. 9 breach │ └─ Unilateral Supplier Security Policy updates ════════════════════════════════════════════════════════════════ NET RESULT: HALDEN EXPOSURE IS UNCAPPED ```

A. The "Data Obligations" Trap (Clause 14.3(c) & Schedule 4)

• Strict Liability for Inherent Inaccuracies: Schedule 4 mandates that Halden *“shall ensure all data uploaded is accurate, complete, lawfully obtained and kept up to date.”* This is a strict-liability warranty, not a reasonable endeavours obligation. Halden’s planners upload hand-compiled spreadsheets with a known 2% to 3% error rate. Halden is in breach of contract the moment an operational planner uploads a manual batch.
• Non-Personal Data Swept into Uncapped Carve-Out: Clause 14.3(c) un-caps breaches of "Data Obligations." Clause 1 defines "Data Obligations" as *all* obligations relating to handling, security, accuracy, or storage of *“any data, whether personal or not.”* If Halden’s inaccurate manual data corrupts Meridian’s analytics engine or causes production faults down the supply chain, Halden’s liability to Meridian is completely uncapped.
• Moving Security Goalposts: Schedule 4 requires Halden to maintain access controls *“in accordance with Supplier’s Security Policy as amended from time to time.”* Meridian can unilaterally update its policy. Because Wolverhampton uses shared planning-floor terminals, Halden is almost certainly in breach of Meridian’s standard access protocols on Day 1.

B. The Circular Indemnity Funnel (Clause 14.3(f) & Clause 11)

• Clause 11 grants Meridian a third-party indemnity for claims arising out of Halden's data.
• Clause 14.3(f) completely un-caps *“any indemnity given under this Agreement.”*
• If Halden uploads supplier contact data without sufficient GDPR Article 6/14 compliance, or uploads proprietary third-party assembly designs without explicit sub-licensing rights, any resulting third-party claim against Meridian passes directly through to Halden on a 100% uncapped indemnity basis—bypassing even common-law mitigation principles.

C. Asymmetry in Consequential Loss (Clause 14.2) While Clause 14.2 excludes consequential loss, third-party indemnities (Clause 11 via 14.3(f)) typically characterize downstream losses as direct liabilities of the indemnitor. Halden absorbs Meridian’s client-facing exposure without the protection of the Clause 14.2 exclusion.

---

2. OPERATIONAL & IT INQUIRY LIST *Before meeting with Meridian's counsel, obtain written confirmation from Halden's internal leads on the following:*

1. Access Control & Identity Architecture (IT Lead):

• *“Can Halden implement unique named user credentials and multi-factor authentication (MFA) on the Wolverhampton shop floor prior to go-live, or does the manufacturing workflow depend on shared terminals?”*
• *Why:* If shared terminals cannot be eliminated immediately, Halden will be in default of standard software security policies from launch.

2. Data Pipeline & Validation (Operations / Planning Lead):

• *“What technical validation occurs before the manual 2-3% error-rate spreadsheets are uploaded to Meridian? What is the worst-case operational impact if Meridian’s analytics engine runs calculations based on these erroneous entries?”*
• *Why:* Determines whether we can accept a qualified warranty (e.g., "material accuracy") or if incorrect uploads threaten the integrity of Meridian's wider platform.

3. Meridian Security Policy Baseline (IT / Security Lead):

• *“Have you reviewed Meridian’s current Security Policy referenced in Schedule 4? Does our current network, browser configuration, and credential management comply with every clause today?”*
• *Why:* Prevents agreeing to incorporate a document that puts the client in immediate default.

4. Data Classification Assessment (Data Protection Officer / HR Lead):

• *“Of the 9,000 records, do any contain special category data, bank/payment details, or critical proprietary IP belonging to Halden’s hydraulic tier-one customers?”*
• *Why:* Establishes the real loss baseline to calibrate the proposed Data Super-Cap.

---

3. PROPOSED REPLACEMENT DRAFTING

A. Clause 14 (Limitation of Liability) > 14.3 Nothing in this Agreement limits or excludes liability for: > (a) death or personal injury caused by negligence; > (b) fraud or fraudulent misrepresentation; > ~~(c) breach of the data obligations in Schedule 4 or of any applicable data protection law;~~ > (c) [DELETED]; > (d) any liability that cannot be limited or excluded by law; > ~~(e) breach of clause 9 (Confidentiality);~~ > ~~(f) any indemnity given under this Agreement.~~ > (e) any indemnity given under Clause 8 (Intellectual Property Indemnification). > > 14.4 Data and Security Super-Cap: Subject to Clause 14.3, each party’s aggregate liability arising under or in connection with: (a) breach of Data Protection Legislation; (b) breach of Clause 9 (Confidentiality); and (c) the indemnity set out in Clause 11 (Customer Data Indemnity), shall be subject to a separate aggregate limit of [£2,000,000 / one hundred and fifty percent (150%) of the Total Charges paid or payable under this Agreement] (the "Data Super-Cap"). > > 14.5 For the avoidance of doubt, claims qualifying under Clause 14.4 shall not count towards the general liability cap set out in Clause 14.1, and satisfaction of the cap in Clause 14.1 shall not exhaust the Data Super-Cap.

B. Clause 1 (Definitions) > "Data Obligations": ~~means all obligations of either party relating to the handling, security, accuracy, storage or processing of any data, whether personal or not, including obligations under Schedule 4 and any service description or policy referred to in it.~~ > "Data Obligations" means the obligations of the parties set out in Schedule 4 to the extent relating to compliance with applicable Data Protection Legislation.

C. Schedule 4 (Data Obligations) > Paragraph 1: Customer shall ~~ensure all data uploaded is accurate, complete, lawfully obtained and kept up to date~~ use commercially reasonable endeavours to ensure that data uploaded to the Platform is accurate, lawfully obtained, and materially up to date at the time of upload. Customer does not warrant that the data will be error-free or uninterrupted. > > Paragraph 2: Customer shall maintain ~~access controls to the platform in accordance with Supplier's Security Policy as amended from time to time~~ reasonable technical and organisational access controls to the platform. Any amendments to the Supplier's Security Policy that materially increase Customer's operational burdens or compliance costs shall require Customer's prior written consent, not to be unreasonably withheld or delayed.

---

4. NEGOTIATION POSITION & CALL STRATEGY

HOLD FIRM (Non-Negotiables / Walk-Aways)

1. No Uncapped Data / Accuracy Liability: Remove Schedule 4 breaches and non-personal data from Clause 14.3 entirely. Halden will not accept uncapped exposure for inventory/supplier data errors.
2. Indemnity De-coupling: Clause 11 (Data Indemnity) must not remain in 14.3(f). It must either sit under the standard Clause 14.1 cap or be tied directly to the Data Super-Cap. Uncapped indemnities for third-party claims arising from uploaded data are commercially unacceptable given Halden's 2-3% operational error rate.
3. De-escalation of Schedule 4 Warranties: Change the strict "shall ensure" warranty regarding data accuracy and completeness to a "commercially reasonable endeavours" standard. Halden cannot warrant 100% accuracy on manual data feeds.
4. Bilateral Protection on Data Super-Cap: Any Data Super-Cap must be mutual. Meridian processes Halden's data; if Meridian suffers a ransomware attack that exposes Halden's 9,000 records, Meridian must be liable under that same Super-Cap.

TRADE (Flexibility / Bargaining Chips)

1. Data Super-Cap Quantum: We can be flexible on the Super-Cap number. If Meridian rejects £2m, we can offer an alternative formula (e.g., 200% of fees paid/payable, or approx. £1.56m) or accept a higher single-purpose cap (up to £3m) provided it is strictly insulated from operational data errors and applies symmetrically to both parties.
2. Payment Schedules / Commercial Terms: Meridian previously wanted upfront annual payments and a firm 3-year term without break clauses. If Meridian resists subjecting the Clause 11 indemnity to a cap, we can trade concessions on payment milestones (e.g., agreeing to pay Year 2 and Year 3 slightly earlier, or shortening payment terms from 60 days to 30 days).
3. Targeted Exclusions from Schedule 4: If Meridian insists on compliance with its Security Policy, we will accept the policy provided it is the *current, version-controlled copy attached as an Annex at signing*, waiving our objection to its specific requirements in exchange for removing their unilateral right to vary it mid-contract.

Memo

To: Partner From: [Your Name] Date: [Date] Re: Review of Limitation of Liability (Clause 14) and Data Obligations (Schedule 4) – Meridian Castings Contract

---

1. Executive Summary

I have reviewed Clause 14 (Limitation of Liability), Clause 1 (Definitions), and Schedule 4 (Data Obligations) concerning the contract with Meridian Castings Software Ltd. While Halden Components Ltd successfully proposed a mutual liability cap of £2 million, there are potential exposures and carve-outs that require attention, especially regarding indemnities, data breaches, and data management practices.

2. Key Exposures and Concerns

• Indemnity Risk:
• Clause 14.3(f) uncaps indemnities, meaning any third-party claims arising from data provided by Halden remain uncapped. This could be a significant exposure, as errors in uploaded data have been noted (2-3% error rate).

• Data Breach Exposure:
• Given the estimated exposure for a breach affecting 9,000 records ranges from £1.5m-£6m, the current liability cap may not sufficiently cover regulatory fines, notifications, and remediation, especially since data breaches are excluded from the cap under 14.3(c).

• Security Concerns and Operational Practices:
• Shared log-ins and manual data entry processes increase vulnerability to data breaches. These practices may not align with robust data protection standards.

3. Proposed Actions

• Adjust the Cap for Specific Risks:
• Propose a "super-cap" for data breach liabilities directly tied to data handling failures due to Halden's practices, setting it at £4 million.

• Clarify Indemnity Provisions:
• Ensure clarity that indemnities only apply if the breaches or inaccuracies are solely attributable to Halden's actions and not due to Meridian's platform execution or integration.

4. Questions for Halden's Operations and IT Leads

• What specific controls are in place to ensure data accuracy and security?
• How frequently are data uploads reviewed for accuracy and compliance?
• How do current practices align with Meridian's security policy?
• What measures are planned to address known vulnerabilities (e.g., shared log-ins)?

5. Proposed Replacement Wording

• Indemnity Carve-Out:
• "Provided that indemnities given under this Agreement shall only apply if the breach is conclusively linked to Halden utilizing negligent or fraudulent practices."

• Super-Cap Addition for Data Breach:
• "The aggregate liability in respect of breach of data obligations, including data breaches attributable to Halden's operational measures, shall not exceed £4,000,000."

6. Negotiation Strategy

• What to Trade:
• Consider trading the firm stance on shared log-ins and in-exchange, accept higher periodic reviews or audits of compliance and data accuracy.

• What to Hold Firm On:
• Maintain full liability for any bare negligence or breach of data obligations caused by Halden, proposing that Meridian shares responsibility for any vulnerabilities on their platform.

7. Conclusion

The existing cap and clause structures expose Halden to substantial liability concerning data management and indemnities. Adjustments can protect Halden better from the expansive financial and operational risks of data breaches. Further discussions with Halden's teams will illuminate internal capability improvements, supporting a refined risk management strategy.

---

Please let me know if further analysis is required.