GDPR and Data Processing

SIMCOAI is built for business customers that need to configure customer support, front-desk calls, chat and workflow records. The business customer decides what data is processed, why it is processed and how long it should be kept for its customers.

SIMCOAI provides the platform, security controls, provider integrations, logs and support needed to process data under those instructions where it acts as processor.

The customer is usually controller for data about its own callers, website visitors, patients, clients, guests, members or shoppers. The customer should maintain privacy notices, lawful basis records, staff instructions, retention policies and DSAR handling.

SIMCOAI should be configured with only the information needed to answer, route or log the customer task.

SIMCOAI is usually controller for account administration, website visitors, billing contacts, support enquiries, security telemetry, legal acceptance records and supplier management.

These records are processed to provide the service, manage contracts, secure the platform, meet legal duties and communicate with business contacts.

Where SIMCOAI processes personal data on behalf of a business customer, the following terms apply and form part of the agreement between SIMCOAI LTD (processor) and the customer (controller). Subject matter: provision of the SIMCOAI service. Duration: the period of active service, any expressly agreed continuing storage period described below, and the deletion or return period that follows. Nature and purpose: hosting, AI-assisted response generation, call and chat handling, workflow records, analytics and support. Categories of data subjects: the customer’s customers, callers, enquirers and staff. Categories of personal data: contact details, communication content and metadata, booking, order and refund details, and related records the customer submits.

SIMCOAI will: (a) process personal data only on the customer’s documented instructions, including as configured in the dashboard, unless required by law to do otherwise, in which case we will inform the customer unless the law prevents it; (b) ensure persons authorised to process the data are bound by confidentiality; (c) implement appropriate technical and organisational measures under Article 32; (d) engage subprocessors only under a written contract imposing materially equivalent obligations, and remain liable for their performance; (e) taking into account the nature of processing, assist the customer with data subject rights requests and with its obligations under Articles 32–36; (f) notify the customer without undue delay after becoming aware of a personal data breach affecting the customer’s personal data; (g) at the customer’s choice, delete or return personal data within 30 days after the end of all agreed processing services, including any expressly agreed continuing storage service, and delete remaining working copies unless UK law requires their storage; and (h) make available information reasonably necessary to demonstrate compliance and allow for audits, which will normally be satisfied by written responses and available documentation.

Continuing storage after cancellation. The customer may expressly agree, through a recorded affirmative acceptance or a separate written agreement, to instruct SIMCOAI to provide continuing storage of its workspace for up to 2 years from the end of subscription access. That agreement must identify the storage purpose and end date. The purpose is to preserve the workspace for possible reactivation; processing during this period is limited to secure storage, backup, necessary security and maintenance, and carrying out the customer’s documented instructions. All processor obligations in this DPA continue during storage. Cancellation, silence or publication of this wording does not by itself constitute agreement to continuing storage.

The customer remains responsible for ensuring that the storage instruction is lawful and necessary for the personal data concerned. It may end storage at any time and choose deletion or return by emailing [email protected]. The 30-day deletion or return period begins when that instruction is received, when the agreed storage period expires, or when active service ends without an expressly agreed storage arrangement, as applicable. If return is chosen, SIMCOAI will arrange secure return and delete remaining working copies within that period, except records UK law requires it to store. Backup copies follow the rotation and restoration safeguards in the retention section below. Continuing storage does not extend paid access or authorise new calls, messages or other customer workflows.

Before go-live, customers should identify lawful bases for customer support, call handling, recordings/transcripts, analytics, marketing follow-up, integrations and retention. Consent, contract, legitimate interests and legal obligation may apply in different places.

Where consent is needed, customers must record and honour it. Where legitimate interests is used, customers should balance business need against individual rights and expectations.

UK PECR rules can apply to cookies, marketing calls, messages and similar technologies alongside UK GDPR. Customers should not use SIMCOAI for marketing outreach without appropriate consent, notices, suppression controls and sender compliance.

Call recording, direct marketing, WhatsApp/SMS templates and tracking technologies need their own checks before launch.

Use the least data needed for the workflow. Avoid free-text collection of card numbers, national identifiers, health data, children data or confidential third-party data unless specifically reviewed.

Short, structured questions usually reduce risk and improve AI quality. Escalate instead of asking for sensitive details.

If an individual asks for access, correction, deletion, restriction, portability or objection, identify whether SIMCOAI or the business customer is the controller for that record. Customer workflow data requests usually belong to the business customer.

SIMCOAI can assist with locating records where technically possible and commercially reasonable, subject to identity, security and legal checks.

Customers should decide retention periods for chats, calls, transcripts, workflow records, analytics and exports. SIMCOAI may keep operational logs, billing records and legal acceptance records for separate security, accounting and legal reasons.

Do not keep transcripts indefinitely just because storage is available. Where the customer expressly agrees to the continuing storage arrangement described in the data processing terms, SIMCOAI retains the customer workspace for up to 2 years from the end of subscription access so the customer can return without rebuilding their configuration. Without that agreement, the 30-day deletion or return provision applies when active service ends. The customer may end continuing storage and request earlier deletion or return at any time. Records required by UK law are retained separately for their applicable periods.

Hourly encrypted recovery copies expire after 30 days at the next scheduled backup run. Erasure from the live service does not immediately remove a record from an older encrypted copy; any restored copy must have later erasures reapplied before it is made available.

Where a business customer uses the customer database, SIMCOAI holds one record per person containing the identifying and contact details that business has collected, together with any additional fields it has chosen to define. A caller is matched to an existing record using the telephone number they are calling from, so a record can be identified before the caller states who they are; matching a record is distinct from confirming the caller’s identity, which is dealt with in the next section. The business customer is the controller of these records; SIMCOAI is a processor.

Deleting a customer record removes that record and unlinks it from the bookings, refunds, orders and escalations it was connected to. Those workflow records are not deleted with it, because they are the business's own trading and accounting history and may be subject to separate retention obligations. Where an erasure request extends to the underlying workflow records, the controller must request that separately and SIMCOAI will action it except where a legal or tax obligation requires specific records to be kept.

Where a business customer defines additional fields on a customer record, that business is responsible for deciding what is recorded in them. Special category data should not be entered into a customer record unless the controller has established an Article 9 condition for doing so.

Before the assistant discusses information already held on a customer record, it establishes whether the person it is speaking to is that customer. Recognising a record and confirming the person are treated as separate steps, and only the second permits disclosure of what is already on the account.

A caller is treated as confirmed where the calling line identity supplied by the telephone network matches the number on the record; where the caller states both the name and the email address held on the record and both match; or where the caller returns a single-use code sent to the email address already on the record. A telephone number spoken by the caller is not accepted as confirmation, because it does not evidence who is holding the line. Where a caller supplies their own email address or an order reference, the assistant assists with the records matching that detail without treating it as a full identity confirmation.

Until a caller is confirmed, the assistant may take a new booking, order or refund request from them and may address them by name, but does not disclose existing records, contact details or the contents of an account. Where confirmation is not achieved, the request is captured and passed to the business customer to handle.

SIMCOAI records the fact of each check: the customer record concerned, the method used, whether it succeeded, and the call it took place on. This is processed for security and fraud-prevention purposes, and is the record by which a controller can demonstrate that a disclosure was made to a confirmed individual. A confirmation applies only to the conversation in which it was obtained and is not carried over to a later contact. These records are held with the customer record and are removed with it; single-use codes are held only for the short period in which they can be used.

The methods above are checks proportionate to a customer-service context. They are not an assurance that impersonation cannot occur. Controllers handling higher-risk requests should configure escalation to a person rather than relying on the assistant to release information.

Use role-based access, strong passwords or OAuth, least-privilege API keys, careful integration scopes, secure staff offboarding and periodic review of billing/admin activity. Credentials stored at rest — SIMCOAI's own supplier credentials, and secrets held on a customer's behalf such as a webhook signing secret — are encrypted with ChaCha20-Poly1305 (RFC 8439), a published 256-bit authenticated encryption standard, individually bound to the record so one cannot be read against another.

SIMCOAI applies technical controls including request rate limits, strict browser security policies, protected administrative routes, pricing and entitlement checks applied on our own systems, isolation of administrative credentials from customer access, and traceable request records used for troubleshooting.

Recovery copies are encrypted before storage with a public encryption key and include the workspace database, sign-in records, stored files and local uploads. The decryption key is held separately. Backups are currently local to the hosting server; separate-site disaster recovery is not yet provided.

Account access data — passkey public keys, authenticator secrets, single-use sign-in tokens and federated identifiers where you use Google sign-in — is processed to authenticate you and to protect the account. Passwords are held and verified by SIMCOAI's own self-hosted sign-in service, which is not a third party, rather than by the SIMCOAI dashboard. It does not expose a readable password back to us: it stores it only as a one-way hash, and the most it offers administratively is a way to set a new one, never to view one already set. SIMCOAI holds no password record for your account, in any form. Passkey private keys remain on your device and are never transmitted to SIMCOAI. No biometric data is processed by SIMCOAI or by the identity provider. Where a passkey or device-based second step is unlocked with a fingerprint or face scan, that verification is performed by your own device and its result — a yes or no — is all that is ever communicated. No fingerprint, facial geometry or other biometric template is collected, transmitted, stored or used to identify you, so no special category data under Article 9 UK GDPR arises from these sign-in methods.

Sign-in events are retained as part of the account audit trail so that you and we can investigate suspicious access. Where you exercise a deletion right, authentication data is removed with the rest of the account record, subject to any retention we are legally required to observe.

Multi-factor authentication cannot be bypassed by SIMCOAI support on request. This is deliberate: an account recovery route that support can trigger is also a route an attacker can social-engineer.

AI should support customer service and routing, not make final regulated decisions. Sensitive topics should be handed to a human. Model responses should be tested with realistic scenarios before production use.

Keep business knowledge updated. Vague or stale knowledge increases hallucination and customer harm risk.

Sign‑in and account security are operated through SIMCOAI's own sign-in service, which runs entirely on SIMCOAI-controlled infrastructure and is therefore not a subprocessor at all — no third party is engaged for authentication. SIMCOAI remains the controller for account‑administration data and, where the customer is controller of end‑customer data, that allocation is unaffected: the sign-in service does not receive end‑customer records, call content, conversation logs or workflow data.

The categories processed for authentication are limited to what a login requires: email address and its verification state, the provider‑issued subject identifier, sign‑in and sign‑out events with timestamp, multi‑factor and authenticator‑app enrolment state, passkey and passwordless registrations, and, where a customer chooses Google, GitHub or Microsoft sign‑in, the account identifier and basic profile claims returned by that provider. A new provider is only ever linked to an existing account at the account holder’s own request, confirmed while signed in on the dashboard’s Security page — a matching email address alone is never sufficient, and any method may be disconnected again as long as one other remains. SIMCOAI stores a linked record containing the user reference, provider name, provider subject, email address, verification flag, basic profile metadata and last sign‑in timestamp, so an account can be matched to its identity across sessions.

Data subject requests are handled by SIMCOAI as the single point of contact. Where a request requires erasure or rectification of authentication records, SIMCOAI actions its own records directly, because the sign-in service runs on our own infrastructure and there is no separate third party to instruct. Authentication data does not leave SIMCOAI-controlled infrastructure, so the international transfer mechanism set out elsewhere in this policy does not arise for it.

Availability of any individual method — passkeys, authenticator apps, email sign‑in links and codes, Google, GitHub or Microsoft sign‑in, or passwordless login — is stated as available where enabled for an account. Nothing in this section is a warranty that a given method is enabled, that authentication is uninterrupted, or that any control prevents compromise.

The customer gives general written authorisation for SIMCOAI to engage the subprocessors needed to run the service, currently including Fasthosts (hosting, servers, storage, domain services and transactional email for the self-hosted database), Stripe (billing), Twilio (telephony and messaging), the managed AI model provider OpenAI for AI responses (SIMCOAI manages their credentials centrally), Deepgram (speech recognition) and ElevenLabs (voice) on phone-enabled plans, Cloudflare (security and delivery) and hosting/monitoring providers. Login and account security run on SIMCOAI's own self-hosted sign-in service, which is not a subprocessor because no third party is engaged. The current list is summarised in the supplier table below and available on request.

We will give notice of intended additions or replacements of subprocessors via the dashboard, documentation or email. If the customer reasonably objects on data protection grounds within 14 days, the parties will discuss in good faith; if no solution is found, the customer may cancel the affected feature or subscription and receive a pro-rata refund of prepaid fees for the unused period.

SIMCOAI lets you send your own records — bookings, orders, refunds, escalations and customer contact details — to other systems, either through our Zapier integration, through a webhook you configure, or by reading them from our API. This clause is about what that means for responsibility, because it is different from the subprocessors above.

These are not SIMCOAI subprocessors. We do not choose them, we have no contract with them for your data, and we receive nothing back from them. When you connect one you are instructing us, as your processor, to transmit your data to a destination you have selected. You remain the controller of that data, and you are the controller of the copy that arrives there. Any transfer outside the UK or EEA that your chosen destination performs is a transfer you are making, not one we are making, and the appropriate safeguards for it are yours to put in place.

What we do on our side. We send only the fields listed in our integration documentation rather than the whole record, we sign each delivery so the receiving system can verify it came from us, and we log that a delivery was attempted. Disconnecting an integration stops future deliveries immediately; it has no effect on data already delivered, which is held by the destination and subject to whatever agreement you have with them.

Before you connect one, satisfy yourself that the destination is somewhere you are willing to send personal data, that your privacy notice to your own customers covers it, and that your retention obligations are met by whoever now holds a copy. A convenient automation is still a disclosure of personal data.

Across the SIMCOAI product, the marketing site and the documentation, the parts of the service are referred to by SIMCOAI names — SIMCOAI Vocatio, SIMCOAI Voice, SIMCOAI Speech, SIMCOAI Intelligence — and the AI models, voices and speech engines have SIMCOAI names of their own. Those names describe configurations SIMCOAI builds, operates and can change; they are not a claim to have built the underlying engines, and they are not used here.

This page names the actual processor, because that is a legal requirement rather than a presentational choice. The table below is the map between the two, so you can tell exactly who processes what when you read a SIMCOAI name anywhere else.

Where a SIMCOAI name is used elsewhere, it always refers to the row above. If SIMCOAI changes the processor behind one of these, this page and the supplier table are updated and notice is given under the subprocessor clause; the SIMCOAI name may stay the same, which is precisely why this map exists.

Some of the suppliers listed above process personal data outside the United Kingdom. Naming the safeguard relied on is a requirement of Chapter V UK GDPR, so it is set out here rather than left to each supplier.

Where SIMCOAI transfers personal data outside the UK, or allows a supplier to do so, the transfer is made on one of the following bases: (a) UK adequacy regulations, where the destination is covered by them; (b) the ICO’s International Data Transfer Agreement; or (c) the EU Standard Contractual Clauses together with the UK International Data Transfer Addendum. Where (b) or (c) applies, a transfer risk assessment is carried out before the transfer begins and repeated if the destination, the supplier or the data materially changes.

Suppliers that may process outside the UK include Stripe, Twilio, OpenAI, Deepgram, ElevenLabs and Cloudflare. The mechanism relied on for an individual supplier, and the transfer risk assessment where one applies, are available to customers on request. Some suppliers also rely on their own certifications, such as the UK Extension to the EU–US Data Privacy Framework; a supplier’s certification is not treated as sufficient on its own without checking that it is current.

Customers with strict location or transfer requirements should raise them before go-live, because some can be met by restricting which features are enabled and some cannot be met at all. Do not assume every workflow is suitable for every jurisdiction without review.

SIMCOAI will notify the customer without undue delay after becoming aware of a personal data breach affecting the customer’s personal data, and will provide information reasonably available to us about the nature of the breach, the categories and approximate number of data subjects and records concerned, likely consequences and the measures taken or proposed. We will cooperate with the customer and take reasonable steps to mitigate the effects of the breach.

If you suspect an incident, preserve logs, timestamps, account IDs and affected workflow details, notify us promptly at [email protected] and avoid deleting evidence until triage is complete. The customer remains responsible for its own controller obligations, including deciding whether to notify the ICO within 72 hours and affected individuals where required.

Higher-risk deployments should maintain records of processing activities and consider a DPIA, especially where call recording, large-scale monitoring, sensitive data, profiling or vulnerable individuals are involved.

SIMCOAI can provide product information to support customer assessments but does not replace independent legal review.

Before launch, confirm privacy notices, cookie notices, call disclosure, recording settings, retention, escalation rules, support contacts, lawful basis records, billing status and test results.

Re-review configuration after plan upgrades, new add-ons, new integrations or changes to customer-facing workflows.

The Customer’s documented instructions include its saved configuration, authorised use of the dashboard and API, connected-system choices, support requests and written directions we accept. An instruction must be specific enough for us to understand the purpose and data involved. If an instruction appears unlawful, technically unsafe or inconsistent with this agreement, we may pause it and explain our concern. We do not have to implement an instruction that would require access to another customer’s data or disclosure of a secret. If UK law requires processing outside the Customer’s instructions, we will inform the Customer beforehand unless that law prohibits notice.

Changes to instructions may require development, a separate fee or a product feature. We will tell the Customer when we cannot perform a request in the requested form and discuss a reasonable alternative. Processing for SIMCOAI’s own billing, security and legal obligations remains our controller activity as explained in the Privacy Policy. This clause does not shift the Customer’s controller decisions to SIMCOAI.

We limit access to Customer personal data to personnel and service providers whose role requires it, subject to confidentiality obligations and appropriate access controls. Access may be needed to operate infrastructure, answer a support request, investigate an incident or comply with law. A support request should contain the minimum example needed to diagnose the issue. The Customer should grant its own Authorised Users permissions suited to their duties and promptly remove access when employment or authority ends.

Where an incident investigation requires wider temporary access, we should record the reason and reduce it again when the investigation ends. Neither party should place passwords, payment card data or other unnecessary secrets in tickets or exported logs. The Customer remains responsible for its employees and contractors; we remain responsible for people acting for SIMCOAI under the processor obligations in this policy.

We may use subprocessors to deliver hosting, communications, billing-adjacent operations, support and other features described in the service. We remain responsible for their processing on our behalf under the applicable data protection terms. We will maintain a current disclosure of relevant subprocessors and give the notice described in this policy for a material addition or replacement. The Customer may object on reasonable data protection grounds by contacting us within the stated notice period and explaining the concern.

The parties will discuss a feasible mitigation, such as disabling an affected feature, changing a configuration or using another available route. If the objection cannot reasonably be resolved, the Customer may end the affected service as the agreement allows, with the applicable refund rights. A provider independently chosen and connected by the Customer is not our subprocessor merely because data passes through the connection; each party must assess its own role and contract for that provider.

Taking account of the nature of processing and information available to us, we will reasonably assist the Customer with data subject requests, security obligations, breach assessment and any required impact assessment or regulator consultation. The Customer should identify the request, its deadline and the data likely involved, and should avoid sending a full identity document unless necessary. We may provide a product export, deletion control, explanation of processing or written security information, depending on the task. The Customer remains responsible for the final response and legal assessment as controller.

Where a request requires work outside normal product controls, the parties will discuss scope and reasonable cost before substantial work begins, unless urgent legal duties prevent delay. We will not disclose another customer’s information to satisfy a request. If we receive a request directly for data controlled by the Customer, we will normally refer it to the Customer and will not answer substantively without instruction, except where law requires us to act.

We will notify the Customer without undue delay after becoming aware of a personal data breach affecting Customer data, using the contact information the Customer maintains. An initial notice may state what is known, what is being investigated and what the Customer can do immediately. We will provide further information as it becomes available, including categories of affected data, likely impact and containment measures where reasonably ascertainable. A security event that does not involve Customer personal data may instead be handled through ordinary service or security communications.

The Customer is responsible for deciding whether and when to notify the ICO or affected individuals for data it controls. We will reasonably assist, but we should not wait for a complete forensic report before giving an initial notice. The Customer should keep its incident contact current and preserve relevant evidence. Neither party should include unnecessary personal data in a broad status update.

At the end of the services involving Customer personal data, the Customer may choose return or deletion as described in this policy and the product’s retention controls, subject to lawfully retained records. The Customer should request an export in time to review it before access ends. We will not claim that data is immediately erased from every backup if recovery copies remain until their normal expiry; such copies are protected from ordinary use and are deleted or overwritten under the applicable schedule. If a restore brings back data that should have been deleted, we will reapply the deletion where feasible.

We may keep limited information as an independent controller where needed for invoices, legal claims, security or compliance, with access and retention limited to that purpose. We will explain a refusal to delete where we can lawfully do so. These end-of-service duties do not grant either party a right to use the other’s confidential information for a new purpose.

We will make available information reasonably necessary to demonstrate compliance with the processor duties in this policy. We may answer a written questionnaire and provide relevant independent reports or summaries under confidentiality where available. If that is insufficient for a specific, substantiated concern, the parties will agree a proportionate further review that protects other customers, service security and privileged information. The Customer should give reasonable notice, avoid unnecessary operational disruption and bear its own review costs unless an agreement or law provides otherwise.

An audit right does not permit penetration testing of production systems without prior written authorisation, access to another customer’s records, or disclosure of secrets that would weaken security. We will address a substantiated deficiency within a reasonable time and explain the planned correction. The Customer may use the information for its compliance purposes but should protect it as confidential information.

For a restricted international transfer that SIMCOAI makes as processor, we will use an applicable UK adequacy regulation, approved contractual safeguard or other lawful mechanism and assess supplementary measures where required. The transfer risk assessment depends on the destination, recipient, data and access controls; it is not a guarantee that the legal environment will never change. We will review a material change in law or provider arrangement and take reasonable steps to maintain a lawful transfer, which may include changing a provider, adding safeguards or stopping the affected processing.

The Customer should separately assess transfers it directs through its own integrations and instructions. If the parties cannot maintain a lawful transfer for a feature, either may suspend that feature to the extent necessary, and the parties will discuss an alternative and any payment consequence under the agreement. We will not silently treat a business’s independent integration as covered by our processor transfer paperwork.

The subject matter of processing is the operation of SIMCOAI functions the Customer enables during its subscription. This may include responding to incoming contacts, recording or transcribing a conversation where enabled, maintaining business knowledge, creating and updating customer records, routing a task, sending a message, preparing an export or connecting a Customer-selected system. Processing lasts for the service term and the applicable return, deletion and lawful retention periods. The Customer can narrow its configuration and should do so where a feature is not needed.

The purpose is to carry out the Customer’s documented business instructions, not to create a separate SIMCOAI relationship with the Customer’s callers or recipients. The people affected may include the Customer’s staff, callers, clients, patients, shoppers, guests or other contacts, depending on the Customer’s business. The categories of data may include identity and contact details, appointment or order information, communications content, evidence provided for a task and technical context. The Customer should not enable collection of special category or children’s data without a lawful basis, appropriate controls and any separate agreement required by the Terms.

The Customer should review this schedule against its actual use and tell us if it plans a materially different use. An enabled field is not an instruction to collect that field from every person. SIMCOAI should process only the data needed to carry out the configured task and support the agreed security and retention functions.

A saved setting, API request from an authorised credential, support ticket from a verified account contact or written change agreed by the parties can be a documented instruction. The instruction should identify the action and, where relevant, the affected records and purpose. SIMCOAI may seek clarification before acting on an ambiguous request that could delete data, disclose it or alter an external system. We will inform the Customer if, in our view, an instruction infringes applicable data protection law, unless law prevents us from doing so.

Where two Authorised Users give conflicting instructions, the Customer should identify who has authority under its own governance. We may pause the disputed action while verifying that authority. We should not use the pause as permission to process the data for our own new purpose. A provider’s technical requirement may constrain how an instruction is performed, but it does not override the Customer’s controller role or our duty to explain a material constraint.

If a legal demand requires us to process data other than on the Customer’s instruction, we will assess the demand, limit the disclosure and give advance notice where permitted. A support suggestion or default setting is not a transfer of the Customer’s legal responsibility for choosing the purpose and lawful basis.

Our measures should be appropriate to the nature, scope and risk of processing and include controlled staff access, authentication, encryption where appropriate, logging, backup and restoration procedures, supplier review, change controls and incident handling. We review them as threats and the Service change. A measure described here is an obligation to apply a suitable control, not a guarantee that no attack or outage can occur. We should test restoration and correct a material weakness within our control.

The Customer controls its own user list, business knowledge, connected-provider permissions and many routing choices. It should assign access by role, remove departed staff, protect credentials, keep its own endpoint devices secure and review logs and records relevant to its work. We remain responsible for the security of the platform and staff access we control. If an incident involves both parties’ systems, the parties should share relevant facts and coordinate containment rather than assuming that one party’s duty cancels the other’s.

A Customer should avoid putting passwords, card details or unnecessary sensitive data into prompts, tickets or general notes. We may reject or isolate unsafe content. If a Customer needs stronger controls for a regulated use, it should discuss them before launch so the parties can determine whether the Service and a written arrangement can support that use.

Before a subprocessor processes Customer personal data for us, we should perform a risk-based review, impose data protection duties no less protective in substance than the relevant duties we owe the Customer, and limit access to what the service requires. We remain responsible for its processing on our behalf. We maintain information about relevant providers and material changes, and the Customer may raise a reasoned objection through the route in this policy. We should investigate an objection rather than treating it as a formality.

A Customer-selected integration is different. The Customer decides whether to connect it, what permissions it receives and whether that provider acts as its processor or independent controller. SIMCOAI remains responsible for securely sending data through the connector it supplies, but does not take responsibility for the independent provider’s whole service. We should make the boundary clear during setup and in documentation where practicable.

If a subprocessor cannot meet a legal or security requirement, we may change it, disable the affected processing or offer an alternative. The Customer retains any cancellation or refund right triggered by a material reduction in the paid service. An emergency replacement may need prompt action; we will provide the notice and information required by the agreement and law.

The Customer is the primary contact for rights requests about its own callers, clients and staff in Customer-controlled workflows. SIMCOAI will assist by making available relevant search, export, correction or deletion capabilities and by providing reasonable information about the processing. The Customer should identify the person and scope using proportionate verification and should consider other people whose information appears in the same call or record. A broad export should not disclose another person’s private information without a lawful basis.

If we receive a request directly, we should identify whether it concerns our own controller data or Customer-controlled data. For the latter, we will normally refer it to the Customer or seek its instruction, unless law requires another response. We should not decide the Customer’s legal exemptions for it. The Customer should give enough lead time for assistance before its statutory deadline; we will prioritise a genuinely urgent request where reasonably possible.

A correction may need to preserve an audit history of the earlier value, especially for a payment, approval or consent record. The parties should explain that distinction to the requester. An export can support portability but may require the Customer to transform fields for its destination. We will not promise compatibility with every external system.

A personal data breach can involve loss of availability, confidentiality or integrity, not only a public leak. We will investigate credible signs of a breach affecting Customer data, contain it where possible and notify the Customer without undue delay after becoming aware of it. An initial notice may be incomplete; we should give verified updates as facts emerge. The Customer should keep its incident contact current and should not wait for a final report before assessing its own notification deadline.

The parties should preserve relevant logs, timestamps, affected record identifiers and containment steps. We should avoid circulating raw personal data beyond the people who need it for the investigation. SIMCOAI will assist with information reasonably available to it about the nature of the event, categories of data, likely consequences and measures taken. The Customer remains responsible for deciding whether to notify the ICO and affected people for data it controls, with our assistance as processor.

We may issue a public status update about service impact, but it may be less detailed than a confidential breach notice. Neither party should describe an unconfirmed suspicion as a confirmed exposure, or conceal a confirmed material fact needed for the other to meet its duties. The parties should review lessons learned and implement proportionate corrections.

At the end of the relevant service, the Customer may choose return or deletion of Customer personal data as provided by this policy, subject to any legal requirement to keep a limited subset. It should ask for an available export while it can still verify the result. We will provide the supported export or a reasonable alternative agreed by the parties, and then apply deletion to live processing within the applicable period. We should identify material technical limits before the Customer relies on a format for migration.

Protected backups may continue to contain a copy until their scheduled expiry. They should not be available for ordinary product use; access is limited to recovery and security purposes. If a backup is restored, we should reapply deletion instructions that were due before the restore where feasible. We should not promise immediate erasure of immutable logs or records we must retain for tax, security, legal claims or a binding demand. Such retained data is restricted to the relevant purpose and not used to provide a new Customer workflow.

The Customer remains responsible for copies it exported or sent to its own integrations. A request to SIMCOAI does not delete data held independently by a recipient selected by the Customer. We will explain that boundary and cooperate with a lawful request directed to data we control.

The Customer may ask for information reasonably necessary to assess our compliance with processor duties. We may provide written descriptions, completed questionnaires, available third-party reports or a proportionate meeting under confidentiality. If a specific concern remains, the parties should agree the scope, timing and safeguards for a further audit. The review should protect other customers’ data, trade secrets, security controls and legal privilege. A Customer may not conduct an unapproved penetration test of production merely because it has an audit right.

We will investigate a substantiated deficiency and explain a correction plan and reasonable timing. If the issue presents immediate serious risk, we may apply an interim control while the full correction is made. The Customer should use audit information only for compliance and vendor management and protect it from unauthorised disclosure. Normal audit assistance should not become a pretext to obtain the whole platform design or another business’s records.

This process does not limit a regulator’s lawful powers or an individual’s rights. If law requires a different inspection or disclosure, the parties will comply while using available protections for confidential information. The Customer remains free to assess whether the resulting evidence meets its own controller duties.

Before making a restricted transfer of Customer personal data, SIMCOAI should identify a lawful transfer mechanism and assess the destination and recipient as required. An adequacy regulation, approved contract clauses or another valid safeguard can provide the legal basis; supplementary technical or organisational measures may be needed. We should not describe a safeguard as a promise that no foreign government request or provider incident is possible. The Customer should assess transfers it directs through its own connected systems separately.

If a transfer mechanism becomes unavailable, we will assess alternatives, including a new lawful mechanism, a different provider, a changed configuration or suspension of the affected processing. We will tell the Customer about a material impact and the practical choices where law permits. We should not continue an unlawful transfer merely because it is convenient. A temporary interruption or permanent loss of a paid core feature is addressed under the Terms and Refund Policy.

The parties should update documentation when the facts change. A provider’s brand, server location or country of incorporation alone may not answer every transfer question; the actual access, data and contract matter. We will provide reasonably available information to help the Customer complete its own risk assessment.

A Customer that adds a new data category, destination or purpose should review its instructions and legal assessment before launch. SIMCOAI should assess whether the requested processing fits the Service, security measures, subprocessors and transfer arrangements. If it does not, we should explain the gap and agree a safe route or decline the feature. A later product update should not silently expand the Customer’s purpose or authorise collection of sensitive data it has not chosen. The parties should keep a usable record of material instructions and changes so that a rights request, incident or audit can be understood later. A preview or beta feature remains subject to the same processor duties. If a change creates a serious unmitigated risk, either party may pause the affected processing while the issue is resolved, with the commercial consequences handled under the Terms.

The parties should retain enough documentation to show the instructions given, material provider changes, security decisions, rights assistance and incident response. The record should be proportionate and protected from unnecessary access. A Customer may need it for its own accountability; SIMCOAI may need it to demonstrate processor compliance. Keeping a record does not authorise indefinite retention of all underlying personal data. Where an audit or rights request identifies an error, the parties should record the correction and update the relevant process. A dispute about whether an instruction existed should be resolved from saved settings, verified communications and event records, not from a later unsupported recollection.