Version 1.0 | Effective 21 September 2026
1. Parties, effect and scope
This Data Processing Addendum (DPA) supplements the PluginChatBot Terms of Service between NAFCORP PTY LTD (ACN 660 556 203; ABN 53 660 556 203), trading as NAFCORP TECHNOLOGIES (Provider), and the customer identified in the accepted account or order (Customer). It applies when Provider handles personal information on Customer's behalf to provide PluginChatBot. It becomes part of the agreement when the Customer accepts the applicable version of the Terms incorporating this DPA or the parties sign an order incorporating it.
Customer ordinarily determines the purpose for collecting information through its website, chatbot or connected channels and the authorised uses of that information. Provider processes that information to supply the service and carry out lawful, documented instructions. If Customer acts for another business, Customer must have authority from that business to give those instructions and engage Provider. These descriptions allocate contractual functions; they do not remove duties imposed on either party directly by Australian law.
This DPA does not treat the Australian Privacy Act as if it used every role, lawful-basis or transfer mechanism found in overseas legislation. It is not, by itself, an EU standard contractual clause, UK transfer addendum, healthcare accreditation or an international-compliance certification. Any additional country-specific agreement must be assessed and adopted separately where required.
For handling necessary for Provider's own account administration, billing, security, legal compliance and customer relationship, Provider acts for those purposes under its Privacy Policy and applicable law. This does not give Provider permission to use Customer's visitor conversations for unrelated advertising or general model training.
Mandatory law prevails. This DPA prevails over an inconsistent general term concerning the handling of Customer personal information. An accepted order may add stronger safeguards but may not authorise unlawful handling or silently remove these protections.
2. Definitions and instructions
Personal information means information or an opinion about an identified individual or an individual who is reasonably identifiable, whether true or not and whether recorded in a material form or not. Customer Data means personal information supplied by Customer, its authorised users, visitors or connected services for processing on Customer's behalf. A Security Incident means unauthorised access to, disclosure, loss, alteration or destruction of Customer Data, or a material compromise of the safeguards protecting it; an unsuccessful blocked attempt alone is not necessarily an incident requiring individual notification.
Documented instructions include the accepted agreement, authorised settings and uploads, enabled integrations and subsequent instructions from an authorised Customer representative. Provider will process Customer Data only for those purposes or as required by law. Provider will tell Customer if an instruction appears unlawful and may pause the affected processing while the parties resolve it. A pause must be proportionate; unrelated service should remain available where reasonably practicable.
Provider will not sell Customer Data, disclose it to another customer, use it for unrelated behavioural advertising, or authorise a model provider to train a general-purpose model on it as part of ordinary service delivery. A proposed additional purpose requires a separate lawful basis and, where appropriate, specific consent and a separate agreement. Retrieving content from a customer's knowledge base to answer a request is not itself permission to use that content to train a general-purpose model.
3. Customer responsibilities
Customer is responsible for identifying its collection purposes, providing accurate and accessible notices, obtaining required consent or other authority, instructing proportionate retention and enabling only appropriate integrations. Customer must minimise unnecessary information, manage its staff's access and maintain the rights or licences needed for uploaded content. It must not ask Provider to use an ordinary support chatbot as an unapproved medical-record system or unreviewed high-impact decision engine.
Customer will provide a contact for privacy requests and incidents, assist in locating relevant records, and notify Provider promptly when an account or credential is compromised or an instruction needs to change. If Customer receives a request from an individual which affects processing by Provider, it will provide sufficient lawful instruction for Provider to assist.
Provider remains responsible for its own processing, security decisions and compliance obligations. Customer's responsibilities do not excuse a breach caused by Provider or remove an individual's rights.
4. Confidentiality and access
Provider will limit access to Customer Data to personnel and authorised service providers who need it for the service, support, security or a legal requirement. Personnel must be subject to appropriate confidentiality obligations and receive relevant instruction. Administrative access must be authorised, proportionate and capable of being reviewed.
Support access to a conversation or uploaded document must be limited to what the support task requires. Provider will not require Customer to disclose account passwords or private keys in an ordinary support ticket. Access must be withdrawn when no longer required, including when a staff member leaves or changes responsibilities.
5. Security measures
Provider will maintain technical and organisational measures reasonable and proportionate to the information, likely harm, services and threats involved. Schedule B describes the measures to be maintained under this agreement. These are contractual commitments, not a representation that a particular third-party certification has been obtained.
Provider will assess material changes affecting security and will not materially reduce agreed safeguards during the service without a lawful, documented basis and appropriate notice. No measure eliminates every risk. This qualification does not remove Provider's obligation to exercise reasonable care or comply with non-excludable law.
6. Service providers and subprocessors
Customer authorises the engagement of the providers identified for the relevant processing in the published Subprocessor and Recipient Register, subject to their stated functions. Provider will take reasonable steps to select appropriate providers, put suitable confidentiality, security and processing terms in place, and assess the safeguards applicable to the service actually used.
Provider remains responsible for the performance of subprocessors it appoints to fulfil its processing obligations under this DPA, subject to applicable law and the agreed liability terms. It will require protections appropriate to the delegated processing rather than relying only on a provider's public marketing statements.
A payment company acting independently for payment, fraud prevention or legal duties is not automatically a subprocessor of visitor conversations. A CRM or messaging service chosen and controlled by Customer may also have its own direct relationship with Customer. The register distinguishes these cases. An internal NAFCORP system is not a separate legal entity, although the external companies hosting or operating it must still be assessed and disclosed where appropriate.
For a proposed new or replacement subprocessor materially handling Customer Data, Provider will give at least 30 days' advance notice where reasonably practicable, identify the function and relevant locations, and allow Customer to raise a reasonable data-protection objection within 14 days. The parties will consider a practical alternative or safeguard. If a material objection cannot be resolved, Customer may discontinue the affected service without an exit penalty and receive an appropriate refund of unused prepaid service.
An urgent security, legal or provider-continuity issue may require a shorter notice period. Provider will give notice as soon as reasonably practicable, explain the circumstances and preserve a meaningful opportunity to address the concern. This mechanism is not permission to make an undisclosed material change in processing purpose.
7. Overseas handling
Provider will identify relevant overseas handling in its Privacy Policy and register, assess contractual and practical safeguards, and take reasonable steps required by applicable law. The agreement does not promise Australian-only storage or processing unless a separate written order expressly defines and confirms that arrangement for every affected service, including support, backups and AI processing.
Where APP 8 and section 16C of the Privacy Act apply, the parties will address their respective obligations and accountability for overseas disclosures. Signing this DPA is not a blanket informed-consent exception to those obligations. A provider's overseas location, a Cloudflare location hint or the existence of an Australian AI endpoint does not by itself establish the location of every processing activity.
If a new country or sensitive-data use introduces obligations not covered by the service, the parties must assess those requirements before enabling that use. Provider may decline a use that it cannot appropriately support.
8. Requests from individuals and regulators
Provider will provide reasonable assistance with locating, accessing, correcting, restricting or deleting Customer Data where appropriate, and with giving an individual reasons for a lawful refusal. Requests must be authenticated in a proportionate way; unnecessary identity documents should not be collected.
If Provider receives a request relating primarily to Customer's visitor records, it will refer the matter to Customer where appropriate and lawful and assist Customer to respond. Provider will also fulfil any obligation it has directly. It will not require an individual to obtain Customer's permission to complain to Provider or a regulator.
Provider will cooperate with a lawful regulatory enquiry and provide relevant information about its processing and safeguards. Neither party may instruct the other to withhold information that must lawfully be disclosed. A legal demand will be assessed, limited to its lawful scope and notified to the other party where lawful and appropriate.
9. Security incidents and breach response
Provider will notify Customer without undue delay after becoming aware of a Security Incident affecting Customer Data. Initial notice may be based on the information then available and will be supplemented as material facts are established. It should describe the incident, affected data and people where known, likely consequences, containment measures, practical protective steps and a contact for updates.
Provider will act promptly to contain and investigate an incident, preserve necessary evidence, reduce harm and address the cause. Customer will cooperate, secure its own systems and supply information needed to assess impact. The parties will coordinate communications without misleading affected people or unnecessarily delaying a legally required notification.
Where the Notifiable Data Breaches scheme applies, each party remains responsible for its own assessment and notification obligations. A suspected eligible breach must be assessed expeditiously; the statutory assessment framework is not a reason to wait before containing an incident or notifying the other party. Australian law does not impose a single universal 72-hour deadline for all privacy breaches. A separate law or overseas regime may impose a different deadline in a particular case.
Customer ordinarily manages communications to its own visitors, with Provider's assistance. Provider may communicate directly where required by law, necessary to protect individuals, or otherwise agreed. Nothing requires prior Customer approval for a notification Provider is legally required to make.
10. Retention, return and deletion
The platform's current ordinary configuration does not delete customer conversations and leads merely because they reach a fixed age. This is not permission to retain personal information indefinitely without a continuing lawful purpose. Customer must assess the need for its records and give appropriate instructions; Provider must also meet its own obligations. Schedule C explains the distinction between service records, operational records and legally retained business records.
On an authorised instruction or at the end of service, Provider will provide reasonable assistance to export or return Customer Data and will delete or de-identify data that it is no longer lawfully required to retain. The parties will agree a practical sequence that avoids accidental loss during an authorised export, preserves rights and does not use deletion to obstruct a complaint. A billing cancellation alone does not identify which visitor records Customer intends to erase.
A deletion request must cover relevant live databases, duplicate or legacy records, integration credentials, applicable provider-hosted files and knowledge resources, and onward systems controlled by Provider. Simply hiding a conversation or archiving a provider project is not represented as complete erasure. Provider will identify a material exception or failed step rather than claiming completion incorrectly.
Residual backups may remain until the relevant backup rotation or deletion process completes. During that period they must be appropriately protected, restricted from ordinary use and not used to restore erased data into normal service without reapplying the deletion instruction. The applicable backup window must be documented and disclosed accurately when relevant; this agreement does not invent a fixed window for an unverified provider configuration.
If a law requires some records to be kept, Provider will retain only what is required, restrict access and use to the lawful purpose, and remove the records when the requirement ends. A financial-record obligation does not justify retaining every conversation, upload or contact for the same period.
11. Assurance and review
Provider will make reasonable information about compliance with this DPA available to Customer, including relevant descriptions of safeguards, incident handling and deletion processes. The parties may normally use written evidence and a scoped review before an intrusive audit, protecting other customers' information and security-sensitive details.
Where reasonably necessary, Customer may arrange a proportionate independent review on reasonable notice, ordinarily no more than once in 12 months. That ordinary frequency does not restrict a regulator, a necessary incident investigation or a justified follow-up to a material unresolved concern. The parties will agree scope, confidentiality and practical arrangements. Provider may not use unreasonable fees or restrictions to prevent verification of a material breach of this DPA. Provider bears its own reasonable remediation costs for its breach.
12. Liability, duration and changes
The Terms of Service apply to liability, disputes and changes, subject to this DPA and mandatory law. In particular, the ordinary contractual liability limitation in the Terms does not apply to privacy, data-security or confidentiality obligations. The parties must expressly approve any different negotiated allocation; it must not remove non-excludable rights.
This DPA continues for as long as Provider holds Customer Data under the agreement, including any restricted residual retention. A change in the processing purposes or a material reduction in protection requires the notice, agreement or consent appropriate to that change. Provider must keep the processing schedules and provider register consistent with the service actually supplied.
Schedule A. Processing description
Subject matter and duration: operating the customer's business chatbot, knowledge retrieval, conversations, lead capture, human support and authorised integrations during service and the limited period needed for lawful return, deletion or retention afterwards.
Operations: receiving, transmitting, storing, indexing, retrieving, generating responses or summaries, rendering supported speech, displaying records to authorised staff, exporting, correcting and deleting. Not every operation applies to every enabled feature.
People concerned: customer website visitors, prospective and existing clients, people contacting connected messaging channels, customer staff and other people whose information is lawfully supplied in authorised content.
Data categories: names and contact details supplied for enquiries; conversation and channel identifiers; messages and generated answers; relevant timestamps, source addresses and handoff metadata; supported attachments and knowledge content; connected records needed for an enabled integration. Sensitive information and high-risk records are excluded from the standard service except for an expressly approved use. Accidental inclusion still requires lawful handling.
Purpose and instructions: the customer's stated support, information and enquiry purposes, limited by its notices, accepted service configuration and lawful written instructions. The customer selects the relevant workspace, bot, permissions and integrations. The provider may process minimum security and usage information to protect and operate the service without turning it into unrelated profiling.
Schedule B. Security commitments on adoption
Provider will maintain access controls that separate accounts and workspaces; protect authenticated requests and administrative interfaces; use encrypted transport for production service connections; protect stored integration secrets with appropriate key management; hash passwords and session tokens appropriately; control and revoke personnel access; and require strong protection for administrative accounts.
Provider will maintain appropriate input and output handling, dependency and vulnerability management, rate and abuse controls, secure deployment practices, monitoring and incident response. Untrusted model text or retrieved content must not grant authority to access another tenant or execute an action. Logs should exclude unnecessary conversation bodies, credentials and other sensitive content.
Provider will test backup recovery and relevant deletion workflows, maintain evidence of key safeguards, and reassess security when a material feature or provider changes. Production settings and recovery evidence must support any specific security representation given to Customer. No SOC 2, ISO 27001, healthcare or data-residency certification is implied by this schedule.
Schedule C. Retention and end-of-service instructions
Customer conversations, messages, leads, contacts and knowledge: retained for the customer's documented service purpose, with no default age-only purge in the reviewed version. The customer must review continuing need and request appropriate erasure; Provider must support that process and comply with its own duties. A customer-specific period may be agreed only after the capability and applicable legal requirements are checked.
Operational and security records: limited by justified operational windows, configured cleanup and necessary incident or legal holds. The internal implementation report records source-code defaults separately from verified production settings. Those defaults are not a guarantee that every expired row is removed at an exact instant.
Account and financial records: retained only for a continuing administration, transaction, dispute or statutory purpose. Legally required financial records may outlast service termination; unrelated visitor content is not included merely because it belonged to a paying account.
Provider-hosted resources and backups: subject to the actual provider configuration, deletion capability and documented backup lifecycle. Provider will disclose material limitations and ensure that a deletion completion notice accurately describes any restricted residual data.
Instruction contact: sales@pluginchatbot.com, with the account or customer website identified. An instruction should state its scope, whether an export is required first and an authorised contact. It must not include passwords or unnecessarily reproduce sensitive visitor records.