Autonomous remediation clause — Serenity tier

Version: 2.0 Effective date: to be set at deployment Status: draft for legal validation Supersedes: support and human cleanup clause from version 1.x

Preamble (informative, non-binding)

This clause defines the remediation mandate you grant to PrestaSecure under your Serenity subscription. It supersedes the previous paragraphs that were limited to human intervention on incident; it adds a clear framework for actions performed remotely on your store by our team or our automated infrastructure, on your behalf.

The intent: tell you exactly what we do on your store, under what conditions, with what guarantees, and what your rights are at any time to reverse or revoke the mandate.

Article 1 — Subject

Under the Serenity subscription, PrestaSecure may perform remote security remediation actions on your PrestaShop store. These actions include, without limitation:

1. applying and rolling back vulnerability patches (CVE patches) to PrestaShop core files, third-party modules, or the embedded software firewall;
2. quarantining, deleting, or restoring files identified as infected, suspicious, or modified relative to PrestaShop's original state;
3. uninstalling orphan, disabled, or compromised modules;
4. adjusting firewall configuration (blocked attack categories, IP allow and block lists);
5. human cleanup interventions following a security incident, including but not limited to webshell removal, restoring core files from an official PrestaShop archive, or hardening file permissions.

This clause applies only to stores covered by an active Serenity subscription. Essentials and Advance subscriptions are never subject to autonomous or remote remediation actions.

Article 2 — Execution modes

For each Serenity-covered store, you choose an execution mode among four levels of autonomy. The mode can be changed at any time from your dashboard with immediate effect.

The default mode at subscription is Operator. You can switch to Autonomous with one click; this is treated as an explicit opt-in and is logged.

Article 3 — Scope of actions

PrestaSecure never acts outside the store covered by the subscription. Specifically:

• no action touches the business database (orders, customers, product catalog);
• no action modifies visual customization files (themes, front-office overrides);
• modifications are exclusively scoped to files and configurations exhibiting a known security vulnerability or a compromise risk identified by our detection engine or our team.

The precise technical bounds of each action type are documented on prestasecure.com and accessible from your dashboard.

Article 4 — PrestaSecure commitments

4.1 Technical safeguards

Before any remediation action, autonomous or operator-driven, the following safeguards apply:

• every patch is tested through an invariant suite covering: preservation of unaffected code, idempotence (the action can be replayed without side effect), reversibility (rollback available), version bound (out-of-scope versions are silently skipped), and post-modification syntactic validity;
• every action is preceded by a restoration point allowing byte-for-byte rollback to the prior state;
• if an action fails mid-execution, the engine halts and notifies you without leaving the system in an intermediate state.

4.2 Rollback SLA

If a regression is observed on your store as a direct consequence of a remediation action, PrestaSecure commits to restoring the prior state within two business hours (Monday-Friday, 8 AM-8 PM Paris time) from notification, by email or via the dashboard. Outside business hours, rollback is guaranteed by 9 AM the following business day.

4.3 Transparency

Every action performed on your store is logged in a journal accessible from:

1. your PrestaShop back-office, in the "History" tab of the PrestaSecure module;
2. your prestasecure.com dashboard, in the "PrestaSecure activity" section;
3. a weekly summary email, which can be disabled at any time from your notification preferences.

Each journal entry shows the action type, date and time, origin (autonomous system, PrestaSecure operator, or cron), final status (success, failure, rollback performed), and where applicable a link to the technical detail.

Article 5 — Customer commitments

For the service to operate, you commit to:

• keeping active and reachable the HTTP cron or system cron that lets your store communicate with our infrastructure (URL provided at module installation);
• not blocking or filtering technical emails we send (incident notifications, explicit consent requests in Suggestion mode or after refusal, weekly summaries when not disabled);
• informing us within reasonable time of any structural change on your store (PrestaShop version upgrade, hosting migration, backup restore) likely to impact remediation actions.

Repeated breach of these commitments may result in automatic service suspension into Suggestion mode, after notification.

Article 6 — Modification and revocation

You can, at any time, from your dashboard:

• change the execution mode of a store (for example switching from Autonomous to Operator or vice versa);
• entirely refuse this remote remediation clause.

In case of refusal, your Serenity subscription is not suspended. The service continues in a configuration equivalent to the version prior to 2.0:

• no remediation action is executed remotely, neither autonomously nor by an operator, without your explicit consent collected by email or phone for each incident;
• the other Serenity components (antivirus scan, firewall, priority support, human intervention on incident at your request) remain unchanged and fully active.

Refusal is revocable at any time; you may accept the clause later from your dashboard without any additional commercial step.

Article 7 — Limitation of liability

PrestaSecure exercises industrial-grade professional diligence to prevent any regression caused by a remediation action: automated tests, version fixtures, automatic rollback on partial failure, human supervision in Operator mode.

Despite these precautions, if a remediation action causes an actual regression on your store, PrestaSecure's liability is limited to:

1. executing the rollback within the SLA defined in article 4.2;
2. where applicable, refunding the downtime directly attributable to the action, prorated against the monthly Serenity rate and capped at one month of service.

Expressly excluded from the liability scope are: indirect damages (lost e-commerce revenue, SEO loss, brand impact), damages caused by a prior store state not detectable by our engine (for example a pre-existing infection that the first action only partially remediates), and regressions caused by external changes between the scan and the action execution (customer deployment, third-party intervention).

Article 8 — Data and confidentiality

Remediation actions rely on the transmission, to our infrastructure, of technical metadata about your store: file paths, file hashes, PrestaShop version, PHP version, activation identifier, action journal.

No business data (customers, orders, catalog) is transmitted under this clause. The processing of these metadata is governed by our privacy policy, available at prestasecure.com, which details retention durations, technical sub-processors, and your access, rectification and erasure rights under the General Data Protection Regulation.

Article 9 — Entry into force

This clause enters into force on the date of your explicit acceptance via the validation window presented at your next login to the prestasecure.com dashboard, or by default at the contract signing date for any new Serenity subscription post-dating the publication of version 2.0.

Existing Serenity subscriptions at the publication date continue under the previous version until explicit acceptance is recorded. Your dashboard presents, at every login, a non-blocking validation window to capture your decision.

Technical annex (informative, non-binding)

Action types and confidence level

Audit trail — data retained per action

• unique execution identifier
• store identifier
• action type and target (file path, CVE identifier, etc.)
• origin (autonomous system, operator, cron, manual customer)
• start and end timestamps
• final status (success, failure, rollback)
• technical details (applied diff, error message where applicable)
• identifier of the corresponding rollback action if any

Mode reference in technical interface

The values full_auto, operator_review, suggest_only, and disabled are the technical identifiers used in the API and in the database. The dashboard displays them under their localized name.

← Retour à l'accueil