Security and Trust

This document sets out how Process AI Pty Ltd (“PAiD”) protects customer data, governs the AI Systems we operate, and meets our obligations under Australian privacy and cyber law. It is the authoritative public statement of our security and AI-governance posture.

1. Purpose, Scope, and Audience

PAiD operates an AI-augmented investigative and financial accounting platform for Australian insolvency, forensic accounting, audit, and SMB clients. Customer engagement data, the AI Systems that process it, and the personnel who operate the platform are the focus of this document.

In scope. The PAiD platform (including managed Postgres production databases, document storage, agent runtime), customer engagement data hosted by PAiD, and the operational practices of PAiD personnel.

Out of scope. Customer source systems (Xero, MYOB, QuickBooks, bank portals), customer endpoints, and any third-party services accessed by customers outside the PAiD-managed boundary.

Audience. Customer security teams, prospective customers, and PAiD personnel.

Practitioner accountability. Insolvency practitioners, registered auditors, and other professional users of the platform retain non-delegable statutory duties under the Corporations Act 2001 (Cth), the Bankruptcy Act 1966 (Cth), and applicable professional standards. PAiD's role is to support these duties, not to replace them. The human-in-the-loop confirmations described in Section 11, the structured audit trail in Section 10, and customer-owned audit log export are designed so that the practitioner can demonstrate that decisions taken in administering an engagement remained their own.

2. Governance and Roles

PAiD operates a single, integrated security and AI governance function.

• Security and AI Risk Officer. A named Security and AI Risk Officer is accountable for this policy, the sub-processor list, and incident response. To limit social-engineering exposure on a public document, the current officer is identified to customers under NDA at engagement start; the role contact for all formal correspondence is available on request via your account management team.
• Navigator (per customer). An Investigative AI Navigator (IAN) or Financial Accounting Navigator (FAN) is assigned at engagement start, accountable for engagement-level adherence to this policy. Subsequent references to “the navigator” in this document refer to this role.
• Review cadence. This document is reviewed at least annually and on any material change to the platform, sub-processors, regulatory environment, or risk profile.

3. Standards Alignment

PAiD's information security management system is structured against ISO/IEC 27001:2022 (information security management) and ISO/IEC 27002:2022 (controls). PAiD's AI management practices are structured against ISO/IEC 42001:2023 (AI management systems).

Control mappings to NIST Cybersecurity Framework 2.0, the NIST AI Risk Management Framework, and the Cloud Security Alliance CAIQ v4 are maintained internally and available to customers under NDA.

PAiD is not currently certified against any of these standards. A roadmap to certification is available under NDA.

For Australian regulatory context, PAiD references the Privacy Act 1988 (including the 13 Australian Privacy Principles, “APPs”), the OAIC Notifiable Data Breaches scheme (“NDB”), and the Australian Signals Directorate's Essential Eight maturity model.

4. Data Classification, Residency, and Sovereignty

PAiD applies a three-tier data classification scheme:

Where engagement materials are subject to legal privilege, court restriction, or enhanced confidentiality undertakings, additional handling is agreed in the engagement contract.

Residency. The PAiD platform's primary data plane (managed Postgres database service and document object storage) is hosted in Australia. All persistent customer engagement data is stored in Australia.

Cross-border processing. Cross-border inference processing is disclosed to every customer at engagement start under APP 8. The contractual prohibition on training and fine-tuning, and PAiD's Zero Data Retention arrangement with the model provider, are set out in Section 13. The platform roadmap targets inference within Australia (target Q4 2026); until that migration completes, the United States remains the sole cross-border destination. The named provider and the payloads sent are set out in Section 14.

Customer data ownership and platform IP. The customer retains ownership of customer input data ingested from source systems and of the final engagement outputs delivered by PAiD. PAiD retains ownership of the platform, including its proprietary skills, prompts, agent logic, and evaluation methods. Ownership of intermediate processing artefacts produced by the platform (audit logs, model rationales, tool-call traces) and the licence under which they are made available to the customer for engagement use, professional record-keeping, and regulatory defence are set out in the engagement contract.

5. Tenant Isolation

Every customer engagement is provisioned its own dedicated Postgres databases: a production database holding the AI-ready data model, and a staging database holding raw source-system data. No engagement's data is reachable from another engagement's data plane, and cross-engagement queries are not supported by any customer-facing tooling. Document storage is partitioned per engagement under prefix-scoped credentials.

Isolation is enforced through three layers:

1. Per-engagement database boundary. Engagement data resides in databases dedicated to that engagement, accessed via connection-scoped credentials issued per engagement. No shared-database multi-tenancy applies.
2. Identity-bound tenant resolution. The engagement context for any data-plane request is derived from the authenticated principal, never accepted as untrusted client input.
3. Row-level security as defence-in-depth. Row-level security policies on engagement tables provide an additional layer of tenant scoping beneath the database boundary.

6. Identity and Access Management

PAiD applies the principle of least privilege across all platform components.

• Personnel access to production data is limited to staff with a documented engagement need. Multi-factor authentication is required on every system holding production credentials. Joiner / mover / leaver processes revoke access within one business day.
• Customer-facing access to operator UIs and APIs requires authenticated sessions; session tokens are short-lived and auditable.
• Service-to-service access uses scoped credentials per service, rotated at least every 90 days and stored in a managed secret store. Credentials are rotated immediately on personnel departure with access or on suspected compromise.
• Administrative database access is gated to engineering personnel with separate audit logging.
• Segregation of duties. AI System configuration and AI output approval are held by different roles. No single individual has unilateral write access to both production data and the corresponding audit log.

7. Cryptography

• In transit. All customer-facing traffic terminates TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled. Cipher suite preference is set to forward-secrecy ciphers. Outbound traffic to model providers and sub-processors uses TLS by default.
• At rest. Each per-engagement Postgres database is encrypted at rest by the managed-database platform. Object storage is encrypted with platform-managed keys at minimum; customer-document storage is migrating to envelope encryption with PAiD-managed customer keys (target Q3 2026). Engagements active when this migration completes are migrated by default; opt-out is available by contract.
• Key management. Application-managed encryption keys are stored in a managed secret store with documented rotation schedule.

8. Data Transfer and Integrations

PAiD ingests customer data through three documented paths:

1. Source-system OAuth APIs. Xero, MYOB, and QuickBooks read-only API connections, initiated by the customer. PAiD never holds or stores source-system passwords.
2. Authenticated SFTP. For documents and bulk extracts that cannot be reached via API.
3. Direct database extract. Under a documented engagement-specific protocol, encrypted in transit and at rest.

Customer data is not accepted via email, shared drive, or unmanaged file transfer.

Document handling on intake. All ingested documents are scanned for malware via a managed scanning service, validated for declared format, and treated as untrusted input within the AI pipeline. Documents that fail malware or format validation are quarantined and flagged to the navigator for review.

9. Secure Development and Change Management

• Source control with mandatory peer review for changes to data-plane code.
• Dependency vulnerability scanning on every build.
• Separation of PAiD's internal development, test, and production environments. Customer engagement data is processed only within the per-engagement databases described in Section 5 (a production database holding the AI-ready data model and a staging database holding raw source-system data, both dedicated to that engagement).
• Change records are linked to engagement impact assessments for changes that affect customer data handling, security controls, or AI System scope.
• No customer data in source control or in PAiD's internal non-production environments.
• Customer change notice. Customers receive at least 30 days' prior notice of platform changes that materially affect data handling, security controls, or AI System scope, except for changes required to address an active security risk, which may be applied with concurrent notification.

10. Logging, Monitoring, and Audit Trail

Each AI System decision presented to the navigator for confirmation, accepted by the navigator, or triggering a downstream platform action is recorded as a structured audit row including timestamp, decision type, confidence score, and reasoning summary. Lower-level inference operations are retained in the inference log under the 30-day retention described below. Authentication events, administrative actions, and data exports are logged to a tamper-resistant store.

Logs do not contain raw customer documents or model training corpora and are subject to the same access controls as production data.

• Audit log retention. Audit logs of AI System decisions and access events relating to a customer's engagement are retained for the lifetime of the engagement plus 12 months. Customers may export their engagement audit log at any time for retention under their own professional record-keeping obligations.
• Inference log retention. Inference request and response logs are retained for 30 days for operational and incident-response purposes.
• Customer audit log access. Customers may request export of their engagement audit log at any time. PAiD fulfils audit log export requests within 5 business days. Use of exported audit logs is governed by the engagement contract. (For privacy access requests under APP 12, see Section 16.)
• Monitoring and alerting. Logs are aggregated to a centralised log store and reviewed by the security team. Anomalous access, authentication failures, and AI System guardrail-bypass attempts trigger alerts via email and on-call paging. The Security and AI Risk Officer holds primary on-call responsibility, with rostered backup as headcount permits. Integration with a managed SIEM is on the platform roadmap (target Q1 2027).
• Network monitoring. Customer-facing network boundaries are protected by managed web application firewall and distributed denial-of-service mitigation provided by the cloud and CDN layer.

11. AI Principles

The following principles govern every AI System PAiD develops and operates.

1. Human accountability. Every AI System operates under a named human navigator. AI outputs are advisory until a human accepts them. No finding, journal entry, or external communication takes effect without human-in-the-loop confirmation.
2. Customer data sovereignty. Customer input data is not used to train or fine-tune any model (PAiD's, its sub-processors', or any third party's). The customer retains ownership of customer input data and of the final engagement outputs delivered by PAiD. Ownership and licensing of intermediate processing artefacts are addressed in Section 4.
3. Provider terms enforced. Sub-processor agreements prohibit training on customer inputs. Zero Data Retention arrangements are entered into where the provider offers them. Operative detail is in Section 13.
4. Tool sandboxing. AI Systems operate inside deny-by-default tool sandboxes. Capabilities are scoped per AI System; write-back to source systems, sending email, and initiating payments are not granted to any AI System.
5. Decision transparency. Every AI System decision recorded under Section 10 is captured with structured metadata (decision type, confidence, reasoning summary, timestamp). The audit trail is available to the customer.
6. Fairness and harm prevention. AI Systems are evaluated against the following risk surfaces prior to deployment and on material change: harm to environment, harm to individuals' physical or mental health, harm to financial position or legal standing, discrimination, and human-rights risk. Material findings block deployment or trigger remediation. The evaluation method is set out in PAiD's AI Impact Assessment process.
7. Lifecycle governance. AI Systems are maintained through documented design, evaluation, deployment, monitoring, and decommissioning stages. Material changes trigger AI Impact Assessment and customer notification per the engagement contract.
8. Incident readiness. PAiD's incident-response programme covers AI Incidents as a distinct class.

12. AI System Governance

Section 11 states the governing principles; this section describes how each principle is operationalised.

PAiD treats every AI System used in the platform as a governed asset. The PAiD AI System Inventory captures, for each active system: model identity and version, prompt and tool scope, intended use, target engagements, last-tested date, and the responsible navigator.

• AI System lifecycle. Each system goes through design, evaluation, deployment, monitoring, and decommissioning stages. Material changes (new model family, new tool capability, scope expansion) trigger an AI Impact Assessment.
• Human oversight. No AI System produces a finding, journal entry, or external communication that takes effect without human-in-the-loop confirmation by the assigned navigator. Confidence-scored AI outputs are advisory until accepted.
• Tool scope. AI Systems operate inside a deny-by-default tool sandbox. Tool capabilities are scoped per AI System and restricted to those required for the AI System's defined task. Write-back to source systems, sending email, and initiating payments are not granted to any AI System. Database access is restricted to the AI System's assigned engagement.
• Prompt-injection mitigation. Documents and source-system content are provided to AI Systems only where the AI System's defined task requires in-context analysis. In all such cases, structured-output enforcement and guardrails apply, and document content is treated as untrusted input within the AI pipeline.
• AI threat surface monitoring. As part of routine operational review, RAG corpus integrity and AI output behaviour are inspected. Detected anomalies trigger AI Impact Assessment review. Continuous in-platform monitoring tooling is on the AI System roadmap.
• Fairness and bias. AI Systems are monitored for systematic bias across customer types and engagement categories. Fairness findings trigger AI Impact Assessment review and remediation.
• AI Impact Assessment cadence. AI Impact Assessments (AIIAs) are performed annually for each in-scope system and on any material change. Each AIIA evaluates intended-use conformance, fairness and bias, adversarial robustness, and confidence calibration. Where an AIIA finds material risk, the AI System is remediated, suspended, or the affected customers are notified, depending on severity.
• Model version change notice. Customers are notified of model version changes that could materially affect output characteristics. Advance notice is provided where the provider's release timeline allows; security patches are applied immediately and notified to customers within 5 business days of application.

13. AI Data Use Commitments

• Customer data is not used to train or fine-tune any model (PAiD's, its sub-processors', or any third party's).
• Where the platform calls a model provider's commercial API, the provider's commercial terms prohibit training or fine-tuning on inputs. Where the provider offers a Zero Data Retention arrangement, PAiD enters into one (currently in effect with Anthropic; scope and carve-out described in Section 14).
• Customer engagement data is never commingled across customers in any model context or RAG corpus.
• The licence under which final engagement outputs and intermediate processing artefacts are provided to the customer is set out in the engagement contract. The training prohibition above applies regardless of licence terms.
• PAiD reviews each model provider's published training-data disclosures and acceptable-use criteria as part of provider onboarding and AI Impact Assessment.

14. Sub-Processors

PAiD engages the following sub-processors in the delivery of the PAiD platform.

Customers receive at least 30 days' prior notice of additions or material changes to this list and the right to object. Customers may request inclusion on the sub-processor change notification list via your account management team. If a customer objects to a proposed sub-processor change, PAiD works in good faith with the customer to identify an alternative; where no alternative is available, the customer's termination rights under the engagement contract apply. Per-customer infrastructure variants are not maintained; pending termination, the proposed change applies to all engagements, with data export available per the engagement contract.

Scope of this list. This list covers sub-processors that materially process customer data on PAiD's behalf. Tools used by PAiD that do not access customer data (collaboration suite, error monitoring, internal communications, source control, marketing tooling) are not enumerated here. Any tool that begins to materially handle customer data is added to this list under the same notice procedure.

New sub-processors are subject to a documented security assessment before onboarding. Assessment criteria include current SOC 2 or ISO/IEC 27001 certification or equivalent third-party assurance, alignment with PAiD's data-handling commitments, and acceptable contract terms (training and fine-tuning prohibition, zero-retention where applicable, breach notification). Material findings block or condition onboarding. PAiD's own certification roadmap is described in Section 3.

Cross-border data flow. The only routine cross-border flow of customer data is prompts and tool-call payloads required for the assigned AI System task, sent to Anthropic's commercial Claude API in the United States. The contractual prohibition on training and PAiD's Zero Data Retention arrangement with Anthropic are stated in Section 13 and reflected in the Anthropic row above. This flow is disclosed at engagement start as required under APP 8.

ZDR scope and carve-out. PAiD's Zero Data Retention agreement with Anthropic covers the Anthropic API products in current use for customer-data inference. Before PAiD adopts any new Anthropic API product (such as the Batch API, Files API, or a hosted connector service) for customer-data processing, the ZDR scope is reviewed with Anthropic and customers are notified of any change to the cross-border data flow disclosure in this document. Anthropic's Usage Policy enforcement carve-out applies even under ZDR: where a session is flagged under Anthropic's published Usage Policy, Anthropic may retain inputs and outputs for up to the period stated in Anthropic's then-current commercial terms (currently 24 months) for safety review. This carve-out applies to all commercial Anthropic API customers and is not specific to PAiD.

Provider transparency. PAiD relies on the model provider's published training-data disclosures, sub-processor disclosures, and acceptable-use criteria. For the current provider, customers may consult Anthropic's published model documentation and trust resources directly.

15. Personnel Security

PAiD personnel are subject to background checks at engagement, sign confidentiality undertakings on engagement, and complete information-security and AI-handling awareness training annually. Account access for departing personnel is revoked within one business day of departure; production credentials previously accessible to that person are rotated immediately on departure (see Section 6).

• Personnel location. PAiD personnel with production data access work from within Australia. Any change to the geographic location of personnel with production data access is disclosed to affected customers in advance.
• Background checks. All PAiD personnel with production data access undergo a current National Police Check on engagement, refreshed every two years. Background checks are scaled to the role's access level. Sample background-check completion attestations, signed by the Security and AI Risk Officer, are available to customers under NDA.
• Endpoint baseline. Personnel accessing production data do so from PAiD-managed devices enrolled in mobile device management, with full-disk encryption, automatic patching, and multi-factor authentication on device unlock. Bring-your-own-device access to production data is not permitted.
• Training content. Awareness training covers phishing and social engineering, customer-data handling, AI-output review (including detection of suspicious or anomalous outputs), AI-specific risks (prompt injection from adversarial documents, social engineering targeting AI-augmented decisions), and incident reporting. Completion is tracked and assessed.

16. Privacy and APP Compliance

PAiD operates under the Privacy Act 1988 (Cth) and the 13 Australian Privacy Principles.

• APP 1. Open and transparent management: this document and the supporting documents are PAiD's public statement of practice.
• APP 3. Collection of solicited personal information: personal information is collected only as needed to deliver the service.
• APP 4. Dealing with unsolicited personal information: where personal information arrives in source-system extracts beyond what is required for the service, it is either retained where lawfully permissible or destroyed.
• APP 5 and 6. Collection notification and use / disclosure: customer engagement data is used solely to provide the service.
• APP 7. Direct marketing: PAiD does not use customer data, customer personal information, or engagement data for direct marketing.
• APP 8. Cross-border disclosure: PAiD discloses cross-border inference processing at engagement start; the destination and named provider are set out in Section 14. PAiD relies on APP 8.1: PAiD takes reasonable steps (including the contractual prohibitions on training and fine-tuning, and a Zero Data Retention arrangement with the provider where one is offered, set out in Section 13) to ensure the overseas recipient does not breach the APPs in relation to the information. PAiD remains accountable under APP 8.1 for acts of the overseas recipient.
• APP 10. Quality of personal information: PAiD takes reasonable steps to ensure that personal information used for AI-augmented analysis is accurate, complete, and up to date relative to its source. The customer is responsible for the integrity of source-system extracts.
• APP 11.1. Security: implemented through the controls described in this document.
• APP 11.2. Destruction or de-identification: where personal information is no longer needed, it is destroyed in accordance with Section 20. PAiD does not rely on de-identification as a primary disposal mechanism.
• APP 12. Access: customers may access engagement data through the assigned navigator. PAiD responds to access requests within 30 days. Where the access request is satisfied by audit log export, the 5-business-day timeline in Section 10 applies.
• APP 13. Correction: customers may request correction of personal information through the assigned navigator. PAiD responds to correction requests within 30 days.

PAiD complies with the OAIC Notifiable Data Breaches scheme. Notification timing and customer notification commitments are set out in Section 17.

17. Incident Response, Breach Notification, and Responsible Disclosure

PAiD operates a documented incident-response runbook covering detection, classification, containment, eradication, recovery, and post-incident review.

Incident classes are:

• Data incidents. Unauthorised access, loss, or disclosure of customer data.
• AI Incidents. Model misbehaviour, prompt-injection compromise, or AI output integrity failure.
• Availability incidents. Service outages affecting customer access.

Notification and reporting commitments:

• Customer notification. PAiD notifies the customer as soon as practicable after the Security and AI Risk Officer confirms that an incident affects the customer's engagement, and in any event within 72 hours of that confirmation. A written report follows within 10 business days.
• Cross-customer notification. An AI Incident is confirmed when the Security and AI Risk Officer determines, on review of triage evidence, that AI System misbehaviour, prompt-injection compromise, or AI output integrity failure has occurred. Where a confirmed AI Incident affects an AI System used by multiple customers, all customers using that AI System are notified within 72 hours of confirmation, with details of whether their engagement was affected and what mitigations are in place.
• NDB scheme. PAiD's obligations under the Notifiable Data Breaches scheme apply to eligible data breaches as defined in Part IIIC of the Privacy Act 1988 (Cth). Where PAiD becomes aware of reasonable grounds to suspect an eligible data breach, PAiD commences assessment as soon as practicable and, where the assessment confirms an eligible data breach, notifies the OAIC and affected individuals as soon as practicable thereafter. Both assessment and notification are completed within the 30-day statutory window.
• AI Incident remediation clock. Where an engagement contract imposes specific AI remediation deadlines (for example, NSW DCS ICTA cl. 6.11(f)(iii) or equivalent), PAiD adheres to the contract. Failure to remediate triggers customer suspension and termination rights as set out in the engagement contract. Related AI-assurance obligations under contracts of this kind (such as cl. 6.11(c) notification of AI use and cl. 6.11(d) AI impact assessment) are addressed by the disclosure practice described in Sections 1 and 4 and the AIIA cadence in Section 12.
• Quarterly AI Incident reporting is provided to customers whose contracts require it.

Responsible disclosure. PAiD welcomes good-faith reports of suspected vulnerabilities or security issues from researchers, customers, and the public. Reports may be submitted via your account management team. PAiD acknowledges reports within 5 business days and will not pursue legal action against good-faith researchers acting under reasonable disclosure terms.

Customer security advisory channel. PAiD operates a security advisory channel; customers may opt in via your account management team to receive proactive notifications of security-relevant changes, advisories, and incident updates.

18. Business Continuity and Disaster Recovery

• Backups. The production data plane is backed up daily with point-in-time recovery covering the most recent 7 days, with weekly snapshots retained for 30 days.
• Recovery objectives. Recovery Time Objective: 24 hours. Recovery Point Objective: 1 hour, supported by continuous transaction log archiving and point-in-time recovery to any moment within the last 7 days. Inference availability is best-effort and depends on model-provider availability; degraded-mode operation is documented. Enhanced recovery objectives are available by contract for engagements with stricter continuity requirements.
• Tabletop exercises are performed annually.
• Capacity management. Compute, storage, and inference quota are monitored against engagement volume; reviewed at least quarterly.

19. Vulnerability and Patch Management

• Dependency scanning on every build; high-severity findings remediated within 30 days, critical within 7 days.
• Infrastructure patching follows the managed-service cadence of our cloud and database providers for platform components; PAiD-managed components are patched on a documented schedule.
• Penetration testing. PAiD commissions an independent penetration test before customer onboarding at sustained scope. Summary letters become available thereafter under NDA. Until then, scoped security reviews on every release and continuous dependency scanning provide vulnerability coverage.

20. Engagement Termination and Data Deletion

On engagement termination:

• Customer engagement data is deleted within 30 days, including the dedicated engagement production and staging databases and document storage.
• Backups containing engagement data expire within the backup retention windows described in Section 18 (7 days for point-in-time recovery; 30 days for weekly snapshots).
• A certificate of destruction is provided on request.
• Sub-processor Zero Data Retention arrangements apply where in place, so customer data is not retained in model weights or inference caches at the provider beyond what is described in Section 14. PAiD's own inference logs follow the 30-day retention described in Section 10.

21. Customer Shared Responsibility

The customer is responsible for:

• Custody of source-system credentials (Xero, MYOB, QuickBooks tokens), even when these are configured by the assigned navigator.
• The integrity of data exported from customer source systems.
• Access to PAiD-issued operator accounts and the periodic review of those accounts.
• Notification to PAiD of any suspected compromise of customer-side credentials.

22. Audit and Evidence on Request

This document and the published sub-processor list are publicly available. The following additional supporting documents are available to customers under NDA:

• The CAIQ-Lite response set.
• A summary of the most recent penetration test when commissioned (see Section 19).
• Architectural diagrams and data-flow narrative for the customer's engagement.
• AI Impact Assessment summary findings for AI Systems used in the customer's engagement, signed by the Security and AI Risk Officer.

Third-party assurance reports (SOC 2 or equivalent) are not currently held; the certification roadmap is available under NDA (see Section 3).

Right to audit. PAiD considers reasonable customer audit requests on a case-by-case basis, scoped to the customer's engagement and timed to minimise operational impact. Audit access, including any third-party-auditor right, is documented in the engagement contract.

Data Processing Agreement. PAiD's data processing terms (purposes, scope of processing, sub-processors, retention, deletion, security measures) are integrated into the engagement contract. A separate Data Processing Agreement is signed where customer policy requires it.

23. Document Control and Contact

• Document owner. Security and AI Risk Officer, contact via your account management team.
• Privacy contact. Available on request via your account management team.
• Incident reporting. Submit via your account management team, next-business-day acknowledgement.
• Responsible disclosure. Submit via your account management team, 5-business-day acknowledgement.
• Insurance. PAiD maintains professional indemnity insurance with cover of A$20 million, in addition to cyber liability insurance. Cover documentation is provided to customers under NDA during procurement.

Last updated: April 2026.