MASHCOR LTD Privacy Policy

Executive summary

We use this Privacy Policy to explain what personal data we collect, why we collect it, the legal bases we rely on, how long we keep it, how we protect it, when we share it, when it may move across borders and the rights available to individuals. We have drafted this notice to align with the UK General Data Protection Regulation and the Data Protection Act 2018, the Privacy and Electronic Communications Regulations for cookies and electronic marketing, and relevant South African POPIA considerations where Mashcor interacts with South African data subjects or operations. We also address AI and automation, including prompts, transcripts, model outputs, hallucination risk, training data restrictions, profiling and cross-border processor arrangements. Primary reference points include the UK GDPR itself, ICO guidance on lawful bases, cookies, automated decision-making, subject access requests, DPIAs and international transfers, the European Commission’s international transfer framework, OpenAI’s business data and DPA materials, and South Africa’s POPIA and Information Regulator guidance on direct marketing, complaints and transborder flows ( UK GDPR, Article 5 ; ICO lawful basis guidance ; ICO cookies guidance ; ICO international transfers guide ; OpenAI data use policy ; POPIA ).

This policy applies to website visitors, prospects, clients, suppliers, partners, chatbot users, voice-agent users and other individuals whose personal data we process in connection with our business. In ordinary website and sales contexts, we act as a controller. In many managed-service contexts, such as client-hosted forms, CRM automations, ad operations, chatbots, voice agents, accessibility workflows, analytics dashboards or data integrations configured on behalf of a client, we may act as a processor and the client remains the controller. Where we act as processor, our processing is governed by the relevant service agreement and, where required, a data processing agreement containing the contractual protections required by Article 28 UK GDPR ( UK GDPR, Article 28 ; ICO controller-processor contracts guidance ).

We do not treat privacy compliance as a one-off document exercise. We aim to apply data minimisation, privacy by design, retention discipline, security controls, rights-handling procedures, breach management and impact assessments where a project or technology is likely to create a high risk to individuals, especially in relation to AI, profiling, voice processing, special category data, children’s data or large-scale monitoring ( UK GDPR, Article 25 ; ICO privacy by design guidance ; ICO DPIA guidance ).

About this policy and our data protection approach

Who we are and how to contact us

MASHCOR LTD is a company registered in England and Wales under company number 17190219, with its registered office at 167–169 Great Portland Street, 5th Floor, London W1W 5PF. Unless this policy says otherwise, MASHCOR LTD is the controller of the personal data described in this notice when you interact with our own website, landing pages, sales team, support team and owned services. You can contact us about privacy, data protection or rights requests at support@mashcor.com , +1 (678) 974-0924 or +27 21 818-6161. A separately named Data Protection Officer has not been publicly specified in this version of the notice. Unless and until we appoint or disclose one, privacy enquiries should be directed to the contact details above.

Scope of this notice

This policy applies to personal data processed through mashcor.com and related digital touchpoints that link to this notice, including website visit data, consultation and lead forms, email or telephone enquiries, client onboarding, support interactions, AI chatbot and AI voice-agent interactions, analytics dashboards, hosted pages, advertising funnels, CRM or API integrations, accessibility tools and related campaign or service operations. It also covers business-contact data from suppliers, partners and professional contacts where such data is handled in the ordinary course of our business.

Our data protection principles

We aim to process personal data lawfully, fairly and transparently; to collect it for specific and legitimate purposes; to keep it relevant and limited to what is necessary; to keep it accurate and reasonably up to date; to retain it only for as long as genuinely needed; and to protect it through appropriate technical and organisational measures. These are not optional design preferences: they are the core principles set out in Article 5 UK GDPR, and they shape our approach to forms, cookies, sales workflows, ad audiences, AI prompts, transcripts, access controls, contract terms and retention schedules ( UK GDPR, Article 5 ).

We also seek to apply privacy by design and default. That means new campaigns, integrations, AI tools, analytics configurations, forms, voice flows and third-party vendors should be reviewed before launch, not only after the fact. Where a project is likely to create a high risk to individuals, we aim to complete and document a data protection impact assessment, define mitigations, restrict the data we collect and confirm the lawful basis before the processing starts ( ICO DPIA guidance ).

Categories of personal data we may collect

The categories of personal data we collect depend on the service, channel and relationship involved. They can include identity and contact data, such as your name, business name, job title, email address, telephone number, postal address and other contact details; commercial and account data, such as contract records, project instructions, service selections, support history, billing contacts and invoice references; website and device data, such as browser type, IP-related information, approximate location, page interactions, campaign parameters, cookie identifiers and referral sources; communication data, such as emails, call notes, chatbot transcripts, voice-agent transcripts, meeting notes and messages; marketing and engagement data, such as subscription preferences, campaign responses, review requests, list membership, routing instructions and opt-out history; and AI workflow data, such as prompts, knowledge-base content, model outputs, summaries, classifications, transcripts and debugging data where these are necessary to run or improve a specific service.

We do not intend our standard services to require special category data, such as health data, biometric data used for unique identification, race or ethnicity, religion, political opinions, sexual orientation or trade union membership. If a client or user sends us special category data anyway, especially through a form, chatbot or voice flow, we will only process it where there is a proper lawful basis, an Article 9 condition, a clear operational need and, where appropriate, a DPIA and contractual controls ( UK GDPR, Article 9 ; ICO special category guidance ).

Sources of personal data

We collect personal data directly from you when you fill in a form, email us, call us, book a meeting, subscribe, start a live chat, use a voice agent, sign a contract or otherwise communicate with us. We also receive personal data from our clients where that is necessary to provide contracted services on their behalf; from integrated systems such as CRMs, analytics tools, ad platforms, payment systems or helpdesk tools; from cookies and similar technologies; and, in limited circumstances, from public-facing business sources such as company websites, professional networking pages, business directories or public listings where this is relevant to business-to-business outreach, service delivery or verification and is lawfully handled.

Data minimisation and operational safeguards

We try to build privacy safeguards into the way data is collected. For example, we aim to ask only for the fields needed for the stated purpose, avoid collecting unnecessary sensitive data, separate service communications from promotional communications, limit broad staff access, restrict prompt inputs in AI workflows, and configure retention and deletion rules rather than keeping everything indefinitely. If a proposed feature, such as a dynamic AI website element, profiling workflow, call transcription process or campaign audience sync, collects more data than is strictly needed, we aim to redesign it or document why the extra processing is necessary and proportionate ( UK GDPR, Article 5 ; ICO privacy by design guidance ).

How we use personal data and our lawful bases

Our approach to lawful basis selection

We only process personal data where we have identified a lawful basis under Article 6 UK GDPR and, where special category data is involved, a separate Article 9 condition. We do not treat consent as a universal fallback. Depending on the purpose, the relevant basis may be contract, legitimate interests, legal obligation, or, in some contexts, consent. We select the lawful basis before the processing begins, explain it in this notice and document it internally where appropriate. ICO guidance is clear that the basis must fit the specific activity and that different activities may rely on different bases even within the same service relationship ( UK GDPR, Article 6 ; ICO lawful basis guidance ).

Source basis for the table design: UK GDPR, Article 6 , Article 9 and ICO lawful basis guidance.

Examples of lawful processing scenarios

If you ask us for a proposal, audit or consultation, we usually rely on contract because you are asking us to take steps before entering a contract. If we keep a limited record of that enquiry and related communication so that we can follow up, avoid duplication and understand business demand, that follow-up may also be supported by our legitimate interests, provided the use is expected, proportionate and not overridden by your interests or rights ( ICO contract lawful basis guidance ; ICO legitimate interests guidance ).

If we place non-essential analytics or advertising technologies on your device, we generally rely on consent, because PECR regulates the use of storage and access technologies separately from the UK GDPR. We therefore do not rely on legitimate interests to bypass cookie consent where consent is legally required ( ICO storage and access technologies guidance ).

If a client asks us to operate a chatbot, voice agent, hosted form or CRM automation that collects or routes personal data on the client’s behalf, the client is often the controller and we act as processor, processing only on the client’s documented instructions and subject to the processor terms required by Article 28 UK GDPR ( UK GDPR, Article 28 ).

Transparency and further information

Article 13 UK GDPR requires controllers to tell people, among other things, who the controller is, why personal data is being processed, what lawful bases apply, who receives the data, how long it will be kept, whether international transfers take place and what rights are available. We use this document to meet those transparency duties and to explain any material limits or operational details that remain unspecified in the public version ( UK GDPR, Article 13 ).

Cookies, marketing and AI-enabled services

Cookies, similar technologies and CMP guidance

We use cookies and similar technologies to operate our website and, depending on your choices and the services you use, to remember preferences, secure sessions, measure site usage, understand campaign performance, route leads, support customer interactions, personalise content and enable advertising or retargeting functions. Under PECR, users must be clearly informed about these technologies, and prior consent is generally required before non-essential cookies or similar technologies are placed or read. The ICO also recognises limited exceptions in narrow circumstances, including certain service-improvement uses, but those exceptions are not a general licence for advertising or broad behavioural tracking ( ICO PECR storage/access rules ; ICO exceptions guidance ).

Our intended compliance approach is that strictly necessary technologies may run without consent where they are genuinely required for the service requested by the user, while analytics, advertising, social-media tags, retargeting technologies and other non-essential trackers should not run until valid consent has been obtained. We also aim to make refusal and withdrawal of consent as easy as acceptance, to keep a record of consent choices, to provide a persistent mechanism for changing cookie preferences and to avoid pre-ticked boxes or deceptive banner design. These are core points in current ICO cookie-consent guidance ( ICO consent-in-practice guidance ).

Exact live cookie names, vendors, lifetimes and category assignments are not yet fully specified in this public version. Before publication, Mashcor should maintain a current cookie inventory through its consent management platform or equivalent governance process and update this notice or a linked cookie notice whenever material tags or providers change.

Marketing communications, PECR, POPIA and TCPA considerations

We may send service-related communications such as account notices, onboarding messages, security notices, billing messages, booking confirmations, support updates and similar operational communications where this is necessary to deliver or administer our services. These are not the same as promotional communications. We may also send promotional emails, SMS messages, calls or similar electronic communications where we are legally entitled to do so and where appropriate consent or another valid basis exists. In the UK, electronic marketing and the use of cookies are also regulated by PECR, so the GDPR and PECR must be considered together, not as substitutes for each other ( ICO PECR electronic and telephone marketing guidance ).

Where consent is required, we seek consent through clear affirmative action and keep records of the time, source, wording or form context associated with that consent where feasible. We honour opt-outs and unsubscribe requests promptly. We may keep a minimal suppression record after an opt-out so that we know not to contact that person again for the same marketing purpose. This is generally necessary to respect the opt-out itself and to evidence compliance if needed.

If we send marketing to South African data subjects using direct electronic channels, we also consider section 69 POPIA and the Information Regulator’s direct-marketing guidance, which emphasise consent requirements and strict limits on requesting it where it has not already been obtained ( Information Regulator direct-marketing guidance ).

If we use voice or SMS workflows that reach recipients in the United States, we also consider the Telephone Consumer Protection Act and related FCC rules. As a general risk-control principle, we aim to obtain the level of consent required by applicable law for autodialled, prerecorded or artificial-voice communications, to record consent where required, and to honour revocation requests made in any reasonable way supported by law ( FCC TCPA overview ).

AI, automation, prompts, training data, hallucinations and intellectual property

We may use AI and automation in connection with website personalisation, chat and voice interactions, workflow routing, summarisation, transcription, content assistance, lead qualification, analytics support, campaign administration, knowledge retrieval, search and support operations. If those systems process personal data, they remain fully subject to data protection law. We therefore aim to limit prompt inputs, collect no more data than necessary, apply role-based access controls, avoid using sensitive data in prompts unless specifically approved, and conduct additional reviews where AI or automation may create materially higher risks to individuals. The ICO is clear that AI systems do not sit outside the ordinary data protection framework simply because they are novel or automated ( ICO AI and data protection guidance ).

We do not intend users to place unnecessary personal data, children’s data, special category data, regulated secrets, payment-card data or other high-risk confidential material into AI prompts or chatbot/voice channels unless we have expressly designed and approved the workflow for that purpose. If you supply such information anyway, we may refuse the input, delete it, redact it, restrict access to it or notify you that the channel is not suitable for that type of information.

AI and automation outputs can be inaccurate, incomplete, misleading, outdated, biased, contextually wrong or entirely fabricated. For that reason, we require human judgment before any AI-generated answer, output, summary, recommendation or draft is relied on in legal, regulatory, financial, healthcare, employment, high-risk safety or other materially significant contexts. This warning is included because it is operationally important, not just legally protective.

We aim to use business-grade AI arrangements for service data where possible. OpenAI states that business products such as ChatGPT Team, ChatGPT Enterprise and the API Platform do not train on business-user content by default, and that API data is not used to train or improve OpenAI models unless the customer explicitly opts in. OpenAI also states that API abuse-monitoring logs may be retained for up to 30 days by default unless a stricter approved control is in place. Where we use third-party AI providers, we aim to select contractual and technical settings consistent with these principles. Exact live AI-provider account types and retention settings are not fully specified in this public version and should be verified before publication ( OpenAI data use policy ; OpenAI enterprise privacy ).

Unless we explicitly state otherwise in a contract or product-specific notice, we do not intend to use client personal data, client prompts or client confidential content to train third-party foundation models for general model improvement. We may, however, store prompts, transcripts and outputs for the duration necessary to deliver the service, maintain security, troubleshoot incidents, evidence performance or comply with law, subject to the retention provisions below. Rights in prompts, source materials and outputs may depend on contract, vendor terms, underlying intellectual-property law and the originality of the content involved. Users and clients remain responsible for ensuring that they have the rights needed to submit source materials and to publish or use outputs.

Profiling in AI or personalisation features

Some Mashcor services may use rules or AI models to tailor website content, route leads, prioritise support, score interactions, classify requests, trigger automations or personalise follow-up. Where these features involve profiling, we aim to keep them proportionate, transparent and low risk. We do not intend to make decisions based solely on automated processing that produce legal effects or similarly significant effects on individuals unless we have a valid legal basis and we provide the safeguards required by law, including human intervention where needed ( ICO automated decision-making guidance ; UK GDPR, Article 22 ).

Third parties, international transfers and security

Analytics, third-party integrations and data sharing

We may share personal data with service providers, professional advisers, infrastructure and platform vendors, payment processors, analytics providers, communications providers, CRM or support vendors, AI providers, advertising platforms, listings networks and other third parties where that is necessary for our legitimate business operations, for contracted service delivery, for compliance or for security and fraud prevention. We do not sell personal data in the ordinary sense of a direct consumer-data resale market. When we share data with processors, we aim to ensure there is an appropriate contract, access restriction, confidentiality obligation and security commitment in place ( UK GDPR, Article 28 ; ICO controller-processor contracts guidance ).

Exact live processor identities can change over time. For that reason, we prefer to maintain a current subprocessor register or trust-centre annex in addition to this general policy. In this public version, several processor categories are identified but the exact vendor roster remains partly unspecified.

Transfer and processor governance sources: UK GDPR, Article 28 , ICO contracts guidance , OpenAI data use policy , OpenAI DPA.

International transfers, adequacy, SCCs and UK transfer tools

Because our business, clients and vendors may operate internationally, personal data may be stored in or accessed from countries outside the UK or outside the jurisdiction in which it was originally collected. Where a transfer is covered by a recognised adequacy arrangement, we may rely on that adequacy framework. Where adequacy is not available, we may rely on appropriate safeguards such as the UK International Data Transfer Agreement, the UK Addendum to the EU Standard Contractual Clauses, the EU Standard Contractual Clauses for EU/EEA transfers, or another lawful mechanism permitted by the applicable law. ICO guidance also emphasises that where safeguards rather than adequacy are used, a transfer risk assessment may be required ( ICO international transfers guide ; ICO IDTA/Addendum guidance ).

For UK-to-EEA and related flows, we monitor the status of UK adequacy regulations and the European Commission’s adequacy decisions. The European Commission publishes its current adequacy decisions centrally, and those decisions can change over time, so this section should be read as describing the transfer mechanisms we may rely on rather than as an immutable statement about every jurisdiction for all time ( European Commission adequacy decisions ).

Where POPIA applies, we also consider the limits on transborder information flows under South African law. In practice, that means we seek to ensure that the recipient is subject to laws, binding rules or contracts providing an adequate level of protection, or that another permitted ground for the transfer exists, such as consent or necessity for contract performance, depending on the circumstances ( POPIA ).

Security measures and breach response

We use a combination of technical and organisational measures designed to protect personal data against unauthorised or unlawful processing and against accidental loss, destruction or damage. These measures may include role-based access control, least-privilege administration, multi-factor authentication where appropriate, encryption in transit, encryption at rest where appropriate, secure hosting practices, patching and vulnerability management, logging and monitoring, backup routines, supplier due diligence, confidentiality obligations, incident response procedures and controlled deletion or de-identification. The exact security profile varies by system and vendor, but the objective is always to match the safeguards to the sensitivity, volume and risk profile of the data being processed ( UK GDPR, Article 32 ; ICO privacy by design guidance ).

No online service can promise absolute security, but we aim to reduce risk and to respond promptly if a security incident occurs. If we become aware of a personal data breach, we assess its scope, cause and likely impact, contain it where possible, document it and determine whether notification is required. In the UK, notifiable breaches must be reported to the ICO without undue delay and, where required, within 72 hours of awareness; if the breach is likely to result in a high risk to individuals, affected individuals must also be informed without undue delay. Under POPIA, the responsible party must notify the Information Regulator and affected data subjects as soon as reasonably possible after discovery of a security compromise, subject to lawful investigation-related delay ( ICO personal data breaches guide ; POPIA ).

Data processing agreement summary

When we act as a processor for a client, we aim to offer or incorporate a data processing agreement that reflects Article 28 UK GDPR and relevant cross-border transfer rules. In summary, that DPA should confirm that we process personal data only on documented instructions, ensure confidentiality obligations for authorised personnel, use appropriate security measures, impose subprocessor controls, assist with rights requests where required, support breach notification obligations, support DPIAs where necessary, and delete or return personal data at the end of the service unless law requires retention. Our DPA should also explain how subprocessors are authorised and how international transfers are legitimised ( UK GDPR, Article 28 ; OpenAI DPA as an example of processor terms structure ).

Rights, retention and complaints

Children’s data and special category data

Our services are generally designed for businesses, professional users and adult decision-makers. They are not primarily directed to children. We do not knowingly solicit or require children’s personal data in the ordinary course of our work. If a specific client project is directed to children or is likely to be accessed by children, that project should be reviewed separately for compliance with the Children’s Code, age-appropriate design principles, profiling controls and any additional consent or safeguarding requirements. Children merit specific protection under data protection law, particularly in relation to profiling, tracking and behavioural techniques ( ICO Children’s Code ).

We do not seek special category data as part of our default website, sales and campaign workflows. If a client in a healthcare or similarly regulated sector asks us to configure forms, automations, chatbot flows or voice flows that may capture health or other special category data, we expect a specific lawful basis, a separate Article 9 condition, clear controller instructions, appropriate security and, where appropriate, a DPIA before that processing starts. We may refuse to enable the workflow until those controls are in place ( UK GDPR, Article 9 ; ICO special category guidance ).

Profiling and automated decision-making

We may use profiling or automation to classify enquiries, personalise content, score leads, prioritise work, route support, detect abuse or suggest campaign actions. We aim to keep such processing proportionate, explain it in context and avoid using solely automated decisions that produce legal or similarly significant effects on individuals unless the law permits it and required safeguards are in place. Where those safeguards apply, they may include human intervention, a chance for the individual to express their point of view and a means to challenge the outcome ( UK GDPR, Article 22 ; ICO guidance on automated decision-making ).

Retention schedule

We do not keep personal data for longer than necessary for the purpose for which it was collected, subject to legal, tax, accounting, fraud-prevention, dispute-management and evidential hold requirements. The table below sets out our intended default publication schedule. These periods may be adapted where a client contract, legal obligation, regulator, security incident or dispute requires a different period. Where an exact live setting is not finalised, that fact is marked as unspecified and should be completed before or immediately after publication ( UK GDPR, storage limitation principle ).

Your rights and how to exercise them

Depending on the circumstances and the law that applies, you may have the right to be informed about how your personal data is used, to ask for access to it, to ask for correction, to ask for erasure, to ask us to restrict certain processing, to object to certain processing including direct marketing, to receive a portable copy of some data where applicable and to obtain safeguards in relation to solely automated decisions with legal or similarly significant effects. The UK GDPR and ICO guidance explain these rights and their limits in more detail ( European Commission information for individuals ; ICO right of access overview ).

To exercise your rights, contact us at support@mashcor.com. If we need to verify your identity, we will ask only for information reasonably necessary to confirm that we are dealing with the right person. We may also ask you to clarify a broad request so that we can respond more efficiently and protect the rights of others. ICO guidance states that subject access requests can be made verbally or in writing, that organisations usually have one month to respond, and that they may extend by up to two further months for complex requests if the individual is informed within the first month ( ICO subject access guidance ).

As of the last updated date of this policy, a dedicated webform for rights requests is not publicly specified. The email address above remains a valid channel for all privacy-related requests.

Workflow basis: ICO subject access guidance , including identity verification, one-month response timing, lawful extensions and clarification of broad requests.

Complaints and supervisory authority contact

If you have a complaint about how we handle your personal data, please contact us first at support@mashcor.com so that we can investigate and try to resolve the issue. You also have the right to complain to the UK Information Commissioner’s Office. The ICO’s published contact details include Information Commissioner’s Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, and the ICO helpline is 0303 123 1113. The ICO’s website also provides online reporting and complaint routes, and it generally expects that you have given the organisation a chance to address the matter first ( ICO contact details ; ICO data protection complaints ).

If your complaint relates to South African processing or rights under POPIA, you may also have the right to complain to the Information Regulator (South Africa) through its official complaints channels ( Information Regulator complaints page ).

Open questions and limitations

This policy is intentionally comprehensive, but some operational details remain unspecified because they are not yet publicly confirmed in the materials available at the time of drafting. These include the exact live subprocessor roster, hosting and CDN vendors, cookie inventory, CMP vendor, payment provider, CRM and support platforms, voice/SMS provider, call-recording configuration, detailed backup overwrite cycle, named Data Protection Officer status and the exact live AI-provider account mix and retention options.

This means the policy is publication-ready in structure and legal logic, but it should still be updated with Mashcor’s final production vendor stack and system-specific settings. The most important operational next step is to publish and maintain a live subprocessor list or trust-centre annex and to align internal retention and deletion settings with the schedule stated above.

Changes to this policy

We may update this Privacy Policy from time to time to reflect changes in our services, systems, vendors, legal obligations, regulator guidance or risk controls. When we make material changes, we will update the “Last updated” date and, where appropriate, take additional steps to bring the changes to your attention. You should therefore check this page periodically for the current version.