This proposed addendum is between the customer named in an executed order and Marco Lorenzo Qureshi Grima, sole trader trading as LimitBreakIT, Malta, contact marco@limitbreakit.com. The supplier's correspondence address is in the service terms. It becomes binding only with the completed processing schedule and the parties' recorded agreement. This is a bespoke template, not the European Commission's unmodified standard clauses or a completed transfer SCC.
1. Roles, scope and instructions
The customer is controller of customer personal data and LimitBreakIT is processor. If the customer is a processor for another controller, LimitBreakIT acts as its subprocessor; the customer must obtain the necessary authorisation and pass on lawful instructions. The customer's order, approved configuration and authorised support/change requests document the instructions, including destinations and permitted transfers. Account/business/security processing for which LimitBreakIT determines its own purposes is described separately in the privacy notice.
Process customer personal data only to deliver the agreed certificate-management service and on documented instructions, unless law requires otherwise. Notify the customer of that legal requirement before processing when legally permitted. Inform the customer promptly if an instruction appears unlawful; pause the affected operation while the issue is resolved. No advertising, sale or unrelated model training with customer personal data is authorised by this addendum.
2. People, access and safeguards
Limit access to authorised personnel bound to confidentiality. Apply appropriate technical and organisational safeguards proportionate to the processing risk, including the measures and limitations in Schedule B. Customer administrators must configure least privilege, supported agents and safe destinations. The supplier remains responsible for its own obligations; shared responsibility does not transfer them wholesale to the customer.
3. Subprocessors
The customer grants general written authorisation only for the approved providers and functions listed in the completed provider register attached to its order. The present candidate register is not customer authorisation. Impose equivalent relevant data-protection duties by written contract and remain responsible to the customer for the subprocessor's performance.
Proposed change procedure: notify the customer's designated contact at least 30 days before a new or replacement subprocessor begins processing its data. Allow an objection on reasonable data-protection grounds during that period. Discuss a workable alternative; if none exists, allow the affected service to end before the change, with an agreed exit and any applicable unused-fee refund. Record the notice and outcome. Website edits alone are not the notification mechanism. This procedure must be adopted before the first customer contract.
4. Assistance and personal-data incidents
Forward data-subject requests concerning customer data promptly to the customer's designated contact. Do not independently respond on its behalf unless instructed or legally required. Assist with retrieval, correction, restriction and erasure, and with security assessments, DPIAs and regulator consultation as reasonably required by the nature of the processing and information available.
Notify the customer without undue delay after becoming aware of a personal-data breach affecting its data. Do not wait for a complete investigation. Give available scope, likely consequences, affected people/records where known, mitigation and a contact; provide updates as facts become available. Preserve relevant evidence with appropriate access restrictions. Notification is not an admission of liability. The controller decides its regulator/data-subject notifications; its potential 72-hour regulator deadline is not a waiting period for the processor. Prove the contact and escalation process before relying on this contractual undertaking.
5. Evidence and audits
Provide information needed to demonstrate these obligations and permit the customer or its independent auditor to conduct appropriate audits, including inspections. Agree reasonable scope and safeguards for other customers and system security. Reports may inform the audit without eliminating necessary inspection rights. Do not impose delay/fees that defeat mandatory rights or incident/regulator access. Document any remedial actions and their follow-through. No SOC 2, ISO certification, external penetration-test completion or immutable audit guarantee is asserted by the current product evidence.
6. International transfers
Only make instructed transfers under a valid applicable Chapter V mechanism, with assessments and supplementary safeguards where required. The Ireland hosting selection does not settle global edge, vendor support or customer-selected destinations. If transfer SCCs are needed, complete the proper module, parties, annexes and choices separately; this addendum does not silently incorporate a signed or assessed SCC. Alert the customer to a conflict that prevents compliance and resolve, suspend or end the affected processing lawfully.
7. Exit, return and deletion
At the customer's choice, securely return or delete its personal data at the end of service and delete remaining copies unless law requires retention. Schedule A must specify the secure return format, active-data deadline, backup expiry and any restricted legal hold. Keep residual backups isolated from ordinary use and reapply deletions/revocations before restored service resumes. Provide a record of completed deletion and justified residual retention. There is no current end-to-end automated tenant-erasure facility or proven exit deadline. Do not execute this addendum until the approved process has passed a scoped drill.
Schedule A: processing description and customer completion
| Element | Proposed scope / completion requirement |
|---|---|
| Subject matter | SaaS certificate lifecycle management for the customer's authorised estate |
| Duration | Agreed service term plus the specifically agreed exit/retention periods |
| Nature and purpose | Receive configuration; authenticate users/agents; discover and inventory; request/reissue, deploy and verify certificates; notify and audit; secure, support, back up and recover the service |
| Data subjects | Customer workforce, administrators, contractors and other people identifiable in configured domains, certificate subjects, contacts, endpoints, logs or notifications |
| Data categories | Names/emails/roles, user and agent identifiers/IPs, hostname/domain/certificate metadata, ownership labels, operational events and timestamps, customer configuration/connection credentials and any personal data in customer-provided fields |
| Sensitive data | Special-category/criminal-conviction data is not intended. Identify and separately approve any unavoidable exposure, safeguards and lawful basis before processing |
| Frequency | Continuous storage with customer actions and periodic agent, lifecycle, discovery and notification activity according to configuration |
| Customer duties/rights | Lawful authority, notices, accurate instructions, approved domains/destinations, controller oversight and all rights provided by this addendum |
| Customer identity and contacts | Must be completed in the order: legal entity, address, controller/processor capacity, authorised signatory and privacy/security/incident contacts with alternates |
| Destinations and transfers | Attach the actual approved CA/DNS/IdP/notification/target list, provider register version, locations and applicable transfer instruments |
| Exit/retention choices | Agree return versus deletion and timings. Proposed 30-day export plus further 30-day active deletion requires approval and proof; no absolute 30-day backup-erasure claim |
| Agreement record | Identify order/version/date and both parties' acceptance; an unsigned document or a page view is insufficient |
Schedule B: technical and organisational measures
| Area | Current evidence and operational limit |
|---|---|
| Transport and access | Pilot HTTPS; organisation-scoped access, RBAC, session/CSRF controls, optional MFA/passkeys/OIDC and key-bound agents. Administrators remain trusted; no external penetration-test certification |
| Storage and credentials | Organisation-bound authenticated encryption for stored connection secrets and hosted key state; pilot encrypted disks and KMS-wrapped master. Service execution can decrypt; agent hosts/destinations hold agent-managed keys |
| Traceability | Per-organisation audit hash chain and lifecycle events. A database administrator can truncate/rebuild local evidence; no external immutable anchoring |
| Recovery | Configured daily encrypted versioned S3 backups in Ireland and verified restore tooling. Lifecycle is not an immutable archive or a guaranteed maximum erasure period. Cloud replacement RTO and customer exit proof remain open |
| Software supply | Signed downloads/worker updates and signed Linux image pre-release. Runtime advisories remain tracked; no vulnerability-free or all-components automatic-update claim |
| Human operations | Restricted production credentials and recorded deployment/custody procedures. Independent recovery witness, incident contact coverage, rights/exit procedures and vendor contract assessments still need adoption/evidence |
Relevant product evidence: Security and key custody. This schedule describes the reviewed state; it is not a claim that every customer configuration is accepted or that the outstanding obligations have already been operationally fulfilled.