← Back to Legal

Service Level Agreement (Employer Tier)

Last reviewed 14 July 2026 · Next scheduled review 11 May 2027

14 July 2026 update: clarified that no order forms are in effect pre-launch (so the Service Credit ladder currently applies to no accounts); corrected the deploy-gating description (deploys are gated on the aggregate GitHub status); replaced “public status page” references with the order-form status channel (Mentum does not yet operate a public status page); made the uptime-measurement wording conditional on production telemetry; and removed a stale SECURITY.md link.

Controller of record: Mentum. Contact: support@mentumjobs.com (operational); privacy@mentumjobs.com (data protection); security@mentumjobs.com (security reports); dpo@mentumjobs.com (DPO routing).

Anchors: Terms of Service § 10 (limitation of liability), § 12 (governing law), § 13 (dispute resolution); Privacy Policy; Sub-processor list; Acceptable Use Policy; Data Processing Addendum.

This Service Level Agreement (“SLA”) forms part of the agreement between Mentum and the Eligible Customer. It is incorporated by reference into the Terms of Service and into any order form between Mentum and the Eligible Customer. The governing law, jurisdiction, and overall limitation of liability are stated in the Terms and apply to this SLA without restatement.

1. Summary and scope

1.1 Purpose

This Service Level Agreement (“SLA”) sets out the availability, performance, recovery, and support commitments Mentum makes to paying employer customers, and the service credits that apply if Mentum falls short. It is the operational counterpart to the Terms of Service: the Terms govern the contractual framework; this SLA quantifies the service standard Mentum commits to deliver inside that framework. Where this SLA and the Terms address the same subject matter, the Terms govern unless this SLA is expressly more specific.

1.2 To whom this SLA applies

This SLA applies to paying employer accounts on a current Mentum order form. Where this SLA conflicts with an individual order form, the order form governs.

This SLA does not apply to:

• Candidate accounts (no fee paid; service is offered without an availability commitment).
• Free, trial, evaluation, beta, preview, or “early access” employer accounts of any kind. Where an account holds a mix of paid and free entitlements, only the paid surface is in scope.
• Features Mentum has labelled “beta”, “preview”, “experimental”, or “AI-powered” — see §§ 4.3 and 8.6 below for the carve-out and the rationale.
• Anyone who has materially breached the Terms of Service or Acceptable Use Policy at the time of an incident.

1.3 Pre-launch posture (read this first)

Mentum is currently pre-launch. This SLA is published so that procurement reviewers, auditors, and prospective customers can see the standard Mentum commits to from day one. The commitments in §§ 3, 4, and 10 are designed to be honest and defensible against Mentum's real architecture, not aspirational. Where a number is qualified as a “target” rather than a guarantee, that wording is deliberate and is preserved when Mentum cannot yet evidence the commitment with operating data (see § 5.3 on the restore drill in particular).

For the avoidance of doubt: because Mentum's payments surface is currently inactive and no order forms are in effect pre-launch, no account is presently an Eligible Customer and the Service Credit ladder in § 7 currently applies to no accounts. The commitments below take effect for a customer only when a paid order form is executed.

2. Definitions

For the purposes of this SLA:

• “Available” means the in-scope Service responds to a successful authenticated request from a synthetic monitor in the United Kingdom with an HTTP status code in the 2xx or 3xx range within ten (10) seconds.
• “Unavailable” means the in-scope Service is not Available, except where the cause falls within an Excluded Event (§ 8).
• “Downtime” means the cumulative number of minutes in a calendar month during which the Service was Unavailable. Discrete incidents of less than five (5) minutes are not counted, matching industry carve-outs for transient network noise.
• “Monthly Uptime Percentage” is calculated as (Total Minutes in Month − Downtime Minutes) ÷ Total Minutes in Month, expressed as a percentage to two decimal places.
• “Scheduled Maintenance” means maintenance announced with at least seven (7) calendar days' written notice, performed within the maintenance window described in § 11.
• “Emergency Maintenance” means unplanned maintenance Mentum performs to address a security vulnerability, data-integrity threat, or critical upstream-vendor change. Mentum will give the maximum notice that is practical in the circumstances and a retrospective summary within twenty-four (24) hours.
• “In-Scope Service” means the production HTTP API at api.mentumjobs.com (excluding endpoints listed under § 8.6), and the production frontend at mentumjobs.com (employer dashboard surfaces only) — or whichever hostnames those services are served from at the time, if Mentum has published a different production origin.
• “Excluded Event” means any of the events listed in § 8.
• “Severity Level” means one of the four severities defined in § 10.1.
• “Business Hours” means Monday to Friday, 09:00 to 17:00 United Kingdom time, excluding UK public holidays observed in England.
• “Business Day” means any day that contains Business Hours.
• “Service Credit” means the percentage of the Eligible Customer's next monthly fee determined by the credit ladder in § 7.2.
• “Eligible Customer” means a paying employer account in good standing under the Terms of Service with no overdue invoice on the date the claim is submitted.
• “Recovery Point Objective (RPO)” means the maximum data loss Mentum targets in the event a database restore is required, measured from the moment immediately before the triggering event to the restore point.
• “Recovery Time Objective (RTO)” means the maximum elapsed time Mentum targets between activation of its Business Continuity Plan and resumption of the affected service.
• “Sub-processor” has the meaning given in the Sub-processor list.

3. Service availability commitment

3.1 Monthly Uptime commitment

Mentum commits to a Monthly Uptime Percentage of at least 99.5% for the In-Scope Service.

99.5% corresponds to a maximum monthly Downtime of approximately 3 hours and 39 minutes in a 30-day month, exclusive of Excluded Events.

3.2 Rationale (not contractual; published for transparency)

The 99.5% commitment reflects Mentum's actual production posture as a pre-launch, single-operator SaaS. The upstream stack — Supabase Pro (database, authentication, storage) and Railway (API hosting, frontend hosting and managed Redis) — operates on a best-effort basis at the spend tier Mentum is on; none of these vendors provide a contractual uptime SLA below their Enterprise plans. Stacking the vendors' published best-effort performance against Mentum's own operational realities — auto-deploy from main gated on the aggregate GitHub status (CI plus the security scan), where a red status skips the deploy, with no staged rollout; a single Supabase project with no read replica; and single-developer incident response — yields 99.5% as the highest figure Mentum can promise without inventing capacity that does not yet exist. Mentum is committed to raising this target once it has both production telemetry to measure against and the capital path to upgrade the upstream stack.

3.3 Endpoint scope

The Monthly Uptime measurement covers:

• GET /api/health and GET /api/ready(liveness and database-connected liveness probes).
• The employer dashboard route group /employer/* rendered by the Next.js frontend.
• The In-Scope API endpoints listed in § 4.1.

Endpoints fanning out to Google Gemini and other third-party AI providers are explicitly excluded from the uptime measurement — see § 8.6.

4. Performance commitment

4.1 Endpoint p95 latency targets

For the following endpoints, Mentum commits to a 95th-percentile (p95) response latency, measured at the application's HTTP boundary in the United Kingdom region, of at most the values shown, over any rolling twenty-four (24) hour window in which the endpoint received at least one thousand (1,000) successful requests.

Each committed p95 is set at approximately twice the corresponding internal performance budget recorded in perf_budgets.yaml. The doubled headroom is deliberate — it absorbs CI jitter, real-world wide-area-network variability, and per-customer load distribution that synthetic tests cannot replicate. Mentum's most recent internal load test (Locust, 50 virtual users, five-minute steady state, dated 2026-04-21) measured the same endpoints at between 110 ms and 510 ms p95, so the public commitment carries substantial operating headroom.

4.2 Why this list and not others

The endpoints in § 4.1 share three properties: they are user-facing, they are deterministic at the application boundary (no third-party model is called inside the request), and Mentum has continuous internal measurement of their p95 today. Endpoints that depend on Google Gemini, ClamAV, the email provider, or any other third party for their response shape are excluded because Mentum cannot honestly commit to a latency it does not control. The full exclusion list is at § 8.6.

4.3 Beta and AI-powered features

The following feature surfaces are not covered by this SLA and may exhibit higher latency, transient unavailability, or feature changes without notice while in beta:

• CV optimisation, enhanced insights, career compass, employer advisor, the what-if simulator, and any chat “suggested reply” surface — all of which fan out to Google Gemini synchronously or asynchronously.
• The matching pipeline's AI-scoring step — match results are produced on a best-effort cadence and Mentum does not commit to a per-candidate freshness window.
• Any future endpoint Mentum marks as “beta”, “preview”, or “AI-powered” in its product surface or release notes.

A feature is brought within the scope of this SLA only by an express written addition to this SLA or an order form signed by Mentum. Silence, omission, or absence of a beta label does not bring a feature into scope. No Service Credit is payable for any failure to meet a latency or availability target on any feature surface listed above or any other feature whose response shape depends on a third-party large-language-model provider.

These features will graduate out of beta and into a future revision of this SLA only when Mentum has either (a) procured a vendor with a contractual latency SLA covering them, or (b) moved them onto an internal architecture that does not depend on a real-time third-party LLM call.

5. Recovery objectives (RTO and RPO)

5.1 Target objectives

Mentum maintains an internal Business Continuity Plan that documents the following targets for recovery from a Supabase-level data-loss event. These are targets, not guarantees:

The platform-wide Maximum Tolerable Period of Disruption (MTPD) of 24 hours is the value Mentum commits to as a non-target floor for catastrophic-scenario recovery; the asset-level RTO/RPO figures are stretch targets bounded by vendor capability.

5.2 Daily backup floor

Independently of the PITR-based stretch targets in § 5.1, Mentum relies on Supabase's daily automated backups with a 7-day retention window (Supabase Pro default). For the avoidance of doubt, in the event PITR is unavailable, the floor RPO is 24 hours based on the most recent daily backup.

5.3 Drill validation status (transparency disclosure)

The targets in § 5.1 are vendor-capability-derived and have not yet been validated by an executed restore drill. The first drill is gated on the availability of a second Supabase project or a real-incident trigger, tracked as item P0-2 in Mentum's internal compliance remediation roadmap. Mentum will publish revised, drill-validated figures in the next annual revision of this SLA after the first drill executes.

Until then, customers should treat the RTO and RPO targets as Mentum's best operator estimate of the recovery posture, not as a binding remedy trigger. Service Credits under § 7 are tied exclusively to Monthly Uptime (§ 3) and committed endpoint p95 latencies (§ 4); failure to meet an RTO or RPO target does not, by itself, give rise to a Service Credit claim.

5.4 Restore decision authority and execution

The decision to initiate a restore sits with Mentum's operator; there is no escalation chain beyond a single person. Customers will be notified by email within the comms cadence in § 10.4 once an activation decision has been taken.

5.5 Relationship to UK GDPR Article 32

This section evidences Mentum's commitment to the availability and resilience of processing systems for the purposes of UK GDPR Article 32(1)(b) and (c) (security of processing — ability to ensure ongoing availability and to restore availability in the event of an incident). The controller-processor terms governing personal data processing are stated in the Data Processing Addendum; this SLA does not vary, supplement, or replace those terms.

6. Measurement methodology

6.1 Uptime measurement

Once production telemetry is wired to a continuous-monitoring provider (see § 6.3), Mentum will measure Monthly Uptime Percentage by:

• Issuing one synthetic probe per minute from a United Kingdom region against GET /api/health (liveness, no database call) and GET /api/ready (database-connected liveness, returns 503 with {checks:{database:"error: …"}} on failure).
• Treating a probe as “failed” when it returns a 5xx, fails to connect, or exceeds the ten-second timeout in the “Available” definition (§ 2).
• Computing Downtime as the count of failed probes within the month, attributed to the minute of the failure.

A future incident response platform will replace this synthetic-only measurement with both synthetic and real-user telemetry. The shift to real-user measurement will be announced by SLA revision (§ 13) at least sixty (60) calendar days before it takes effect.

6.2 Performance measurement

Mentum measures committed-endpoint p95 latency (§ 4.1) over any rolling twenty-four-hour window in which the endpoint received at least one thousand (1,000) successful (2xx) requests. The 1,000-request denominator exists so that low-traffic windows cannot statistically register as breaches on a handful of cold-cache outliers.

Measurement excludes time spent before the request reaches the application HTTP boundary (TLS handshake duration, end-user network latency, last-mile ISP delay) and any time spent in a third-party service excluded under § 8.

6.3 Production telemetry pre-requisite

Production p95 telemetry will be wired to a continuous-monitoring provider before this SLA goes into effect on a customer's order form. Until then, the committed p95 figures in § 4.1 represent design budgets validated by continuous-integration load testing rather than measured production behaviour. Customers may request the measurement provider configuration as part of pre-contract security review.

6.4 Data source for claim disputes

If a customer disputes Mentum's calculation of Downtime or a p95 breach, the customer may request the underlying telemetry data for the affected period. Mentum will provide the data within ten (10) Business Days of a verified request. Mentum is the authoritative measurer for the purposes of this SLA; the data is provided for transparency, not as a substitute measurement.

7. Service Credits

7.1 Service Credits are the sole and exclusive remedy

Subject to § 12.1, the Service Credits in § 7.2 are an Eligible Customer's sole and exclusive remedy for any Mentum failure to meet the commitments in §§ 3 and 4. Service Credits do not give rise to a right of refund, cash payment, set-off against amounts owed for other services, or termination of the agreement. Nothing in this section excludes or limits any liability that cannot lawfully be excluded or limited under English law, including liability for death or personal injury caused by negligence, fraud, or fraudulent misrepresentation (see Terms of Service § 10 final paragraph).

7.2 Credit ladder — Monthly Uptime

Where Monthly Uptime Percentage falls below 99.5% in a calendar month, the Eligible Customer is entitled to the following Service Credit applied to the next monthly fee due under their order form:

7.3 Credit ladder — Performance commitment

Where a committed-endpoint p95 in § 4.1 is exceeded over any rolling twenty-four-hour window meeting the request-volume threshold in § 6.2, and Mentum does not restore compliance within seventy-two (72) hours of becoming aware of the breach, the Eligible Customer is entitled to a Service Credit of 10% of the next monthly fee. Concurrent breaches across multiple committed endpoints in the same calendar month are credited once, not stacked per endpoint.

7.4 Combination of credits

If both an uptime breach and a performance breach occur in the same calendar month, the Service Credit is the greater of the two ladder outcomes, not the sum.

7.5 Aggregate cap

The total Service Credits Mentum may be required to issue under this SLA for any single calendar month shall not exceed 50% of the Eligible Customer's monthly fee for that month. Aggregate credits across all months in any rolling twelve-month period are bounded by the overall liability cap in the Terms of Service § 10.

7.6 Worked example

An Eligible Customer paying £1,000 per month, where Monthly Uptime falls to 98.6% in a given month, is entitled to a £250 Service Credit (25%) applied to the next month's invoice — converting that invoice into a £750 amount due. If, in the same month, the committed p95 for GET /api/chat/conversations is also breached and not remediated within 72 hours, the credit remains £250 (the greater outcome under § 7.4), not £350.

8. Exclusions

The following events are Excluded Events and the time during which they cause Service unavailability or performance breach does not count towards the calculation of Monthly Uptime Percentage, committed p95 latency, or recovery objectives.

8.1 Scheduled Maintenance

Maintenance performed within the window described in § 11, with the notice period required by that section.

8.2 Emergency Maintenance

Unscheduled maintenance Mentum performs to address a security vulnerability, data-integrity threat, or critical upstream-vendor change, provided Mentum acts in good faith and gives the maximum notice practical in the circumstances.

8.3 Force majeure

Acts of God; natural disasters; war, armed conflict, or acts of terrorism; sanctions; government action, regulation, or order materially affecting Mentum or its sub-processors; large-scale internet backbone or DNS outage; or any other event outside Mentum's reasonable control.

8.4 Sub-processor outage

Outage of, performance degradation at, or material change in service from any sub-processor on the Sub-processor list, explicitly including:

• Supabase (database, authentication, storage, realtime). Status: status.supabase.com.
• Railway (API hosting and frontend hosting where applicable). Status: status.railway.com.
• Google Gemini (LLM API for AI-powered features). Mentum's daily Gemini spend ceiling may also return HTTP 503 with a Retry-After header when reached; time spent in this state is excluded.
• Twilio SendGrid (transactional email).
• Mentum's Redis provider (rate limiting, async task store, idempotency-key store, cost-guard daily counter). When the platform is configured to fail closed on Redis unavailability, time spent in this state is excluded.
• ClamAV (optional malware scanning of CV uploads, when enabled).
• Sentry (error monitoring).
• GitHub (CI / CD).

8.5 Customer-caused issues

Any unavailability, performance breach, or apparent error arising from:

• Customer use that materially breaches the Acceptable Use Policy or the Terms of Service.
• Customer or end-user network, hardware, or browser configuration.
• Customer exceeding Mentum's published rate limits (the per-endpoint limits documented in Mentum's API).
• Customer integration code, custom scripts, or third-party tools the customer wires into Mentum's API.
• Invalid credentials, expired tokens, or admin sessions older than the four-hour cap.
• Customer-initiated bulk operations that breach the rate-limit guarantees.

8.6 AI-powered and beta feature surfaces

Any feature surface flagged in § 4.3 as beta or AI-powered, including but not limited to: CV optimisation, enhanced insights, career compass, employer advisor, what-if simulator, chat suggested replies, the matching pipeline's AI scoring step, and any future endpoint Mentum labels “beta”, “preview”, or “AI-powered”. The exclusion exists because the latency and availability of these features is bound by Google Gemini, which provides no SLA on its developer-tier API. The carve-out in this section operates together with § 4.3: a feature within scope of either carve-out is outside the scope of the uptime measurement (§ 3), the performance commitment (§ 4), the recovery objectives (§ 5), and the Service Credit ladder (§ 7).

8.7 Sub-five-minute incidents

Discrete incidents of less than five (5) minutes duration. Network noise and routine vendor blips are not actionable Service breaches.

8.8 Authentication and session events out of Mentum's control

Time spent in the post-JWT-rotation 401-storm window during a Supabase JWT secret rotation (typically up to 60 seconds), and time spent with sessions logged out as a consequence of an Eligible Customer's password rotation, OAuth provider re-authorisation, or admin session four-hour expiry.

8.9 Free, trial, beta, and unbilled accounts

Any account, or any portion of an account, that is not on a paying entitlement on the date of the incident.

9. Reporting and claim process

9.1 Incident reporting (Eligible Customer to Mentum)

To report a suspected SLA breach, the Eligible Customer must email support@mentumjobs.com with the subject prefix [SLA] and include:

• The Eligible Customer's account identifier and the order-form reference.
• The affected calendar month, or the rolling-window start and end timestamps for a performance claim.
• A description of the impact, with timestamps in Coordinated Universal Time (UTC).
• Where available, any x-trace-id values captured from error toasts or response headers (Mentum stamps a UUID4 trace ID on every request).
• The remedy the customer believes applies under §§ 3, 4, or 7.

9.2 Time bar

A claim for a Service Credit under § 7 must be received by Mentum within thirty (30) calendar days of the end of the calendar month in which the alleged breach occurred. Claims received after this period are not eligible for a Service Credit under this SLA. This time bar applies only to the contractual Service Credit remedy under this SLA and does not affect any statutory limitation period applicable to a cause of action the Eligible Customer may have under English law.

9.3 Mentum response

Mentum will acknowledge a [SLA]-prefixed claim within two (2) Business Days of receipt and will issue a written decision within ten (10) Business Days. Where the decision is to grant a Service Credit, the credit will be applied to the next monthly invoice issued after the decision date.

9.4 Disagreement and escalation

If the Eligible Customer disagrees with Mentum's decision, the customer may within twenty (20) Business Days request a single review at the operator level, providing any additional information or supporting evidence. Mentum's review decision is final under this SLA, without prejudice to the customer's general rights under the Terms of Service § 13 (dispute resolution) and applicable law.

9.5 No credit without a claim

Service Credits are not issued automatically. The claim process in this section is a condition precedent to entitlement.

10. Support response times

10.1 Severity definitions

10.2 Response and resolution targets

10.3 Support hours and channel

Support is provided on a best-effort basis during Business Hours via email at support@mentumjobs.com. There is no 24/7 phone support, no named technical account manager, no out-of-hours escalation chain, and no dedicated chat channel at this tier. Mentum operates as a single-operator business pre-launch; the support response targets in § 10.2 are written against that operating reality and will tighten as Mentum's support headcount grows.

Outside Business Hours, Mentum's automated controls (daily Gemini spend ceiling, security-anomaly detection every five minutes, cron-clip detection every thirty minutes) provide the operational safety net. A customer-raised Sev-1 received outside Business Hours is acknowledged at the start of the next Business Day.

10.4 Status communications

For Sev-1 incidents, Mentum will:

• Post an update to the status communication channel designated in the order form (Mentum does not yet operate a public status page) within thirty (30) minutes of operator awareness and at least every thirty (30) minutes thereafter until the incident is resolved.
• Issue a customer-facing email to all Eligible Customers within four (4) hours of operator awareness, using Mentum's internal incident comms template.
• Publish an internal post-mortem within five (5) Business Days of resolution; a summary will be shared with Eligible Customers on request.

For Sev-2 incidents the update cadence on the designated channel is two (2) hours; for Sev-3 and Sev-4 incidents Mentum does not commit to proactive status updates.

10.5 Vulnerability reports

Security vulnerability reports follow the separate process in the SECURITY.md policy in Mentum's repository, available on request via security@mentumjobs.com — acknowledgement within 72 hours, triage within 7 Business Days, disclosure window 30-90 days from initial report. Vulnerability reports are not Sev-1 by default; the security process applies whether or not the reporter is an Eligible Customer. Report security issues to security@mentumjobs.com.

10.6 GDPR personal data breach notification

In the event of a personal data breach within the meaning of UK GDPR Article 4(12), Mentum's notification to the Information Commissioner's Office (Article 33) and, where required, to affected data subjects (Article 34) follows the 72-hour clock independently of and in priority to the SLA support targets above. See the Privacy Policy.

11. Scheduled maintenance windows

11.1 Standing window

Mentum's standing maintenance window is Sunday 03:00 to 05:00 UTC, chosen to align with the lowest-traffic period in Mentum's cron schedule. Mentum may use up to four (4) hours of cumulative maintenance time per calendar month within this window. Time spent on maintenance within the standing window is treated as Scheduled Maintenance and is excluded from the calculation of Monthly Uptime Percentage under § 8.1.

11.2 Notice

Mentum will give at least seven (7) calendar days' written notice before performing Scheduled Maintenance. Notice is delivered to the email address on the Eligible Customer's order form and to the status communication channel designated in the order form (Mentum does not yet operate a public status page).

11.3 Emergency Maintenance

Emergency Maintenance may be performed outside the standing window when necessary to address a security vulnerability, data-integrity threat, or critical upstream-vendor change. Mentum will give the maximum notice practical in the circumstances and a retrospective summary within twenty-four (24) hours.

11.4 Annual JWT and credential rotation

Mentum rotates its Supabase JWT secret on at least a quarterly cadence and on any suspected secret leak. Each rotation produces a brief window (typically under 60 seconds, occasionally up to two minutes) during which Mentum's API returns HTTP 401 on every request. This is treated as Emergency Maintenance under § 8.2 and is excluded from the uptime calculation; Mentum will pre-announce planned rotations whenever they can be scheduled in advance.

12. Limitation of liability and survival

12.1 Limitation of liability cross-reference

The Service Credits in § 7 are subject to the overall limitation of liability in the Terms of Service § 10 (Limitation of Liability), including the 12-month aggregate cap stated in that section. Nothing in this SLA extends, varies, or supplements Mentum's liability beyond the cap set in the Terms. The Terms § 10 final paragraph continues to apply: liability for death or personal injury caused by negligence, fraud, or fraudulent misrepresentation, and any liability that cannot be excluded or limited under English law, is not excluded by this SLA.

12.2 No warranty beyond commitments

Other than the express commitments in §§ 3, 4, 5, 10, and 11, the Service is provided on an “as is” and “as available” basis. The disclaimers in Terms of Service §§ 7 (AI-generated content), 8 (third-party data sources), and 10 (limitation of liability) continue to apply.

12.3 Survival

Sections 2 (Definitions), 6 (Measurement methodology), 7 (Service Credits), 8 (Exclusions), 9 (Reporting and claim process), 12 (Limitation of liability and survival) and 14 (Contact) survive termination of the agreement to the extent necessary to resolve any claim properly raised under § 9 before the date of termination.

13. Changes to this SLA

Mentum may revise this SLA from time to time. Material changes — including any change to a committed uptime percentage, a committed p95 endpoint or its target, the credit ladder, the claim process, the time bar, or the scope carve-outs — will be notified to each Eligible Customer's order-form email address at least sixty (60) calendar days before the revised SLA takes effect. Non-material editorial changes (typographical corrections, link rewrites, restating the same commitment in clearer language without altering substance) take effect on update of the “Last reviewed” date at the top of this document; Mentum will not use this route to make a material change.

Where a material change disadvantages the Eligible Customer, the Eligible Customer has the right to terminate the affected order form by written notice given at least thirty (30) days before the revised SLA takes effect, without further liability to Mentum beyond fees accrued to the date of termination. Continued use of the Service after the revised SLA takes effect constitutes acceptance of the revised SLA, save where the Eligible Customer has exercised the termination right in this section.

14. Contact

• SLA claims, support tickets, dispute escalation: support@mentumjobs.com (subject prefix [SLA] for SLA claims).
• Data protection, DSAR, privacy questions: privacy@mentumjobs.com; DPO routing: dpo@mentumjobs.com.
• Security vulnerability reports: security@mentumjobs.com.
• Information Commissioner's Office (UK supervisory authority): ico.org.uk/make-a-complaint — 0303 123 1113 — Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF.

Related: Terms of Service | Privacy Policy | Acceptable Use Policy | Sub-processors | Data Processing Addendum | Cookie Policy