Data Processing Agreement

This agreement is part of the Terms of Service and governs the processing that Alexander Fregonese, self-employed professional (sole trader) established in Spain, Tax ID (NIF) Y3260770M ("the processor") carries out of the personal data the agency ("the controller") stores in the CRM about its clients, leads, candidates and contacts. It is written to satisfy Article 28 of the GDPR, which applies to us as a processor established in the European Union, and the service-provider requirements of US state privacy laws.

The agency decides what data it stores, for what and for how long, and is responsible for having a legal basis to do so. We process it solely on its instructions and to provide the service to it. For the purposes of the California law (CCPA/CPRA) and the equivalent laws of other states, we act as a service provider: we do not sell or share the data, we do not use it outside the relationship with the agency, we do not combine it with data from other sources except to provide the service, and we certify that we understand and will comply with these restrictions.

The instructions are: the Terms of Service, this agreement, and the agency's use of the CRM (what it stores, sends, connects and deletes). If we believe an instruction breaches the law, we will say so before carrying it out. We will not process the data for any other purpose.

Only staff who need it to provide the service or resolve an incident access the data, under a written confidentiality obligation, and every access to a sensitive item is logged. We do not access an account's content for support unless the agency asks.

We apply the technical and organizational measures in Annex I, appropriate to the risk of the data the CRM stores (which includes financial identifiers and health data). We review them periodically and improve them without lowering the level of protection.

The agency authorizes the subprocessors on the Subprocessors list, which is part of this agreement. We have a contract with each of them with data protection obligations equivalent to those of this agreement, and we are answerable to the agency for what they do.

The database lives in the European Union. Subprocessors that process data in the United States do so under the safeguards the GDPR requires (standard contractual clauses or the EU-US Data Privacy Framework, as applicable to each). Data of US agencies and their clients therefore travels between the United States and the European Union; the agency authorizes those transfers as part of its instructions.

If we want to add or replace a subprocessor, we will notify the organization's owner by email and in the CRM 15 days in advance. If the agency has a reasonable ground to object and we find no alternative, it may cancel the service without penalty before the change takes effect.

• Data subject rights: if an agency's client writes to us, we forward it without delay; the CRM lets the agency view, correct, export and delete a person's data by itself. If it needs technical help, we provide it.
• Risk assessments and consultations with authorities: we provide the information about our processing that the agency needs.
• Security questionnaires from the agency's carriers or auditors: we answer them.

If we confirm an incident affecting the agency's personal data (unauthorized access, alteration, loss or disclosure), we will notify the organization's owner without undue delay and, at the latest, within 72 hours of confirmation, by email from cleverioai@gmail.com to the owner's address.

The notice will include what we know at that point: what happened, which data and which people were affected (or an estimate), what we have done to contain it and what we recommend the agency do. We will complete it as we learn more and cooperate in the notifications the agency must make to its clients or to authorities. The agency can also report to us an incident it detects on its side, at the same address.

When the contract ends, the agency can export its data (clients, policies, form responses) from the CRM for 30 days, and ask us for the sensitive data encrypted through a secure channel. After that period we delete all the organization's data from our active systems and confirm it in writing on request. The provider's backups are overwritten in their normal cycle (seven days) and are not used to restore data of a deleted organization. We keep only what a law requires us to keep, and the audit trail with no sensitive data.

So the agency can verify that we comply with this agreement, we provide documentation of our security measures, our providers' certifications and answers to its questionnaires. If that is not enough, it may carry out an audit (itself or through an independent third party bound by confidentiality), once a year, with 30 days' notice, during business hours, without accessing other organizations' data, and at its own expense.

As a service provider to financial institutions, we undertake to: maintain the safeguards in Annex I to protect the nonpublic personal information of the agency's customers; use it only to provide the service; notify the agency of any incident under section 8; and allow it to assess our safeguards under section 10.

The CRM is designed to be able to handle protected health information with the safeguards HIPAA requires of a business associate (encryption, access control, audit trail, minimum necessary). Even so, that regime applies only when a Business Associate Agreement (BAA) has been signed.

If the agency is a covered entity or a business associate under HIPAA, it must request the BAA at cleverioai@gmail.com and sign it before uploading protected health information. Without a signed BAA, the agency undertakes not to upload protected health information subject to HIPAA into the CRM, and bears any consequence of doing so.

Each party's liability for breach of this agreement is governed by the Terms of Service, including its limitation of liability. Each party is answerable to data subjects and authorities for its own legal obligations; the agency is answerable for the lawfulness of the data it stores and the instructions it gives.

• Access control: every user has their own account with a password (hashed) or Google sign-in; two-step verification available and enforceable per organization; roles (owner, administrator, agent) that limit what each one sees and does; user removal with immediate effect.
• Isolation between organizations: row-level security policies in the database itself for every business table; no application query can bypass them; privileged keys live only on the server.
• Encryption: HTTPS for all traffic; column-level encryption (server-only key) for SSNs, bank details and email bodies; decryption only through controlled functions that log every read; integration tokens encrypted.
• Audit trail: reads of sensitive data, exports, deletions, integration connections, role changes and invitations, and platform administration actions, with who, what and when; the trail survives the deletion of what it describes.
• Minimization: sensitive data is never written to logs or sent to analytics providers; the standard export excludes it; the Copilot does not receive it; the form editor warns when a question asks for a sensitive item in free text.
• Application protection: origin verification on every write; rate limits and brakes against automated abuse; byte-level validation of uploaded files; signed, expiring download links; secrets only in server environment variables.
• Communications: consent recorded with source and date before any automation writes to anyone; unsubscribe link and headers in every commercial email; sending caps and automatic pauses on complaints or bounces.
• Continuity: daily backups by the database provider; a test environment separate from production; no test ever runs against real data.
• Development: change review, type checking and an automated test battery (including organization isolation and encryption tests) before every deployment; database migrations reviewed so they never destroy data.
• Providers: only those on the Subprocessors list, under contract, with prior notice of any change.
• People: staff access limited to what is necessary, under confidentiality obligations; automatic alerts to platform administration on security signals (revoked tokens, limits reached, repeated failures).