This statement is published by ACUITY INTELLIGENCE SG PTE. LTD. (Singapore UEN 202633032N), registered at 68 Circular Road, #02-01, Singapore 049422. "Acuity", "we", "us" and "our" refer to that company. It applies to the Acuity websites, Website Intelligence service, customer workspaces, supported integrations and related systems that Acuity owns or operates.

Acuity's security objective is to protect the confidentiality, integrity and availability of the Service and the information entrusted to it. We use a risk-based approach that considers the sensitivity of data, the purpose of processing, foreseeable threats, contractual commitments and applicable law.

This statement describes Acuity's control intentions and public commitments. A control is represented as implemented only after the accountable owner has confirmed that it operates for the stated scope. Product components and providers may use different technical measures. Acuity does not claim a certification, audit result, penetration-test scope, availability level, data location or encryption standard unless it is expressly identified, dated and scoped in this statement or an assurance document issued by Acuity.

Security is shared among Acuity, Customers, Authorised Users and Connected Services. Acuity secures the systems and processes it controls. Customers must protect their users and devices, assign appropriate roles, authorise only necessary integrations, review Output and actions, and comply with their own legal and security obligations. Connected providers remain responsible for their independent platforms.

No internet service, transmission or storage method is completely secure. Acuity cannot guarantee that every threat will be prevented. We aim to reduce risk, detect and respond to events, learn from incidents and improve safeguards over time.

Acuity assigns responsibility for security, engineering, privacy, incident response, vendor risk and AI governance. Material risks and exceptions are assigned to an accountable owner, prioritised according to impact and likelihood, and tracked through remediation or formal acceptance.

Acuity maintains internal policies and standards proportionate to its size, services and risk. Relevant controls are reviewed at least annually and after a material product, architecture, provider, legal or threat change. The public Security & Trust statement is reviewed quarterly and after a material control change.

Security and privacy risk are considered during feature design, integration approval, vendor onboarding and material change. The assessment may consider data categories, access paths, tenant boundaries, threat scenarios, provider dependencies, human impact and recovery needs.

Where a standard control cannot be applied, the owner must document the reason, risk, compensating measure and review date. An exception does not convert a planned control into an implemented control and must not be used to support an inaccurate public claim.

Acuity classifies information according to sensitivity and business impact. Categories may include public information, internal business information, confidential Customer Content and restricted information such as credentials, access tokens, sensitive personal data and security secrets.

Acuity seeks to collect and retain only information reasonably needed to provide, secure, support and improve the Service, comply with law and meet contractual commitments. Detailed collection, use, retention, deletion and individual-rights information appears in the Global Privacy Policy at /legal/privacy.

Customer Content is handled according to the Customer's instructions, workspace configuration, access permissions, Terms & Conditions, Privacy Policy and applicable DPA. Customers must not upload unsupported restricted data and must limit access to people with a business need.

OAuth tokens, API keys, webhook secrets and similar credentials are treated as restricted information. They must be stored only in approved systems, made available only to authorised services or personnel, protected from ordinary logs and user interfaces, and revoked or rotated when no longer required or when compromise is suspected.

Acuity uses Stripe-hosted or Stripe-provided payment interfaces for supported payments. Customers must enter card data only in those approved fields. Acuity does not require complete card numbers or card-security codes in Customer Content, support requests, email or ordinary application fields.

Acuity is designed to keep each customer workspace logically separated through identity, authorisation and data-access controls. Requests to access workspace data must be associated with an authenticated identity or authorised service context and evaluated against the relevant tenant, role and permission.

Acuity may use shared cloud, application and database infrastructure. Shared infrastructure does not mean that one Customer is authorised to access another Customer's content. Logical boundaries, scoped identifiers, permission checks and service-provider controls are used to limit access.

Engineering changes that affect tenant identity, authorisation, data queries, object storage or exports should receive review and testing proportionate to the risk. Suspected cross-customer exposure is treated as a security incident and investigated under the incident-response process.

Customers control many workspace settings, including membership, roles, connected accounts and approval workflows. A Customer must review those settings, remove stale access and avoid granting broader permissions than a user's duties require.

Acuity requires supported production web traffic and service-to-service communications that carry confidential data to use encrypted transport through current provider-supported protocols. Exceptions must be documented and must not expose confidential data over an untrusted network.

Acuity uses managed storage and database protection capabilities for production data where the approved provider supports them. Coverage, key ownership and implementation may differ by component. Acuity does not publish a universal algorithm or key-management claim until the architecture and configuration for that scope have been verified.

Production secrets must not be committed to source code or exposed through public client applications. Access is limited according to role and service need. Secrets are rotated or revoked when exposure is suspected, when a privileged user leaves or changes role, or when provider and risk requirements make rotation appropriate.

Where a provider supports request signing, state or nonce validation, redirect-URI restrictions or token expiry, Acuity uses those controls as appropriate to the integration. Integrations must validate the calling context and must not trust unverified external input.

Acuity requires unique user identities for ordinary interactive access. Authentication methods depend on the feature and may include passwordless, password, federated identity or multi-factor options. Available methods and session controls are displayed in the Service or applicable plan.

Workforce and service access to production systems and Customer Content is limited to authorised roles with a legitimate operational need. Privileged access should use strong authentication, separate or elevated roles where appropriate, and logging proportionate to risk.

Access is approved before grant, reviewed when responsibilities change and removed promptly when it is no longer required. Privileged and sensitive access is reviewed periodically. Shared credentials are avoided unless a service requires them and compensating controls are documented.

Customers must assign roles based on job need, protect administrator accounts, use available strong-authentication options and remove former users promptly. Administrators are responsible for reviewing the effect of integration scopes and approval settings before enabling them.

Material features and integrations are reviewed for foreseeable security, privacy and AI risks. The review considers data flow, trust boundaries, permissions, abuse cases, error handling, provider obligations and the effect of a compromised account or service.

Production changes should be traceable to an authorised change and receive peer or accountable-owner review proportionate to risk. Changes to authentication, authorisation, payments, tenant separation, data deletion and consequential actions receive heightened attention.

Acuity uses a combination of automated checks, developer testing and targeted manual review appropriate to the component. A successful test does not prove that the Service is free from vulnerabilities. High-risk changes may require additional security review before release.

Development and testing activity should be separated from production operations. Production Customer Content must not be copied into a non-production environment unless authorised, necessary and protected with controls appropriate to its sensitivity.

Production deployments are controlled and traceable. Material changes should have a rollback, disablement or mitigation path where reasonably practicable. Emergency changes may use an accelerated process but remain subject to subsequent review.

Acuity uses risk-appropriate methods to identify vulnerabilities in code, configurations, dependencies and exposed services. These may include automated dependency or code checks, provider alerts, testing and reports from users or security researchers.

Suspected vulnerabilities are assessed for exploitability, exposure, affected data, tenant impact and available mitigations. Acuity prioritises remediation based on risk rather than relying only on a numerical score. Critical active risk may require emergency restriction, rotation, patching or feature disablement.

Software and service dependencies are reviewed and updated according to risk, compatibility and provider support. Unsupported or materially vulnerable components are remediated, isolated, replaced or subject to a documented exception.

Material remediation is reviewed or retested to confirm that the intended issue has been addressed and that the change has not created an unacceptable new risk. Relevant evidence is retained according to the security record schedule.

Acuity will describe an independent penetration test or assessment publicly only when the scope, date, assessor independence and result are current and approved for disclosure. Vendor assessments and certifications are not represented as Acuity's own.

Acuity records security-relevant events appropriate to the feature, which may include authentication, administrative changes, permission grants, integration activity, consequential approvals, errors and security alerts. Logging is designed to support operation, investigation, accountability and legal obligations.

Access to security logs is restricted according to role and need. Logs should not contain secrets or full payment-card credentials. Relevant records are protected from ordinary alteration and retained for a period proportionate to their purpose, as described in the Privacy Policy and internal schedule.

Acuity monitors available operational and security signals to identify suspicious behaviour, failures and potential incidents. Detection coverage varies by system and evolves with the Service. Alerts are triaged according to potential impact and urgency.

Where supported, Customers may view audit or activity records for their workspace. A Customer should contact support promptly if it identifies unexpected access, configuration or action.

Acuity maintains a process to identify, assess, contain, investigate and remediate suspected security incidents. The response may include preserving evidence, revoking access, isolating a component, rotating secrets, engaging providers or advisers, restoring data and applying corrective actions.

An incident is assessed according to affected systems, information, Customers and individuals; the likelihood and severity of harm; continuing risk; contractual duties; provider requirements; and applicable notification law.

Acuity will notify affected Customers, individuals, regulators or other parties where and when applicable law or contract requires. A notice may be delayed or limited where law enforcement or another legal requirement directs it, or where facts are still being verified. Acuity will not make a fixed universal notification promise that conflicts with applicable law or an agreed DPA.

Acuity will provide information reasonably needed for an affected Customer to meet its obligations, subject to security, confidentiality and legal restrictions. Material incidents are reviewed to identify lessons and corrective actions.

Report a suspected Acuity security incident to support@acuityintelligence.io with the subject "Security Incident". Do not send passwords, private keys, complete payment-card data or unnecessary personal data.

Acuity designs production services to use provider and application capabilities appropriate to their importance and risk. Resilience may include managed redundancy, controlled deployment, retry or queue mechanisms, monitoring, backup and documented recovery procedures.

Where backups are used, access is restricted and backup copies are protected according to their data sensitivity. Backups are intended for recovery, not ordinary use, and expire according to approved schedules and provider capabilities.

Restoration procedures and recovery priorities are tested at a cadence proportionate to service risk. Acuity will publish a recovery-time or recovery-point commitment only when it is documented in an applicable Order or approved service-level statement.

Acuity considers material provider failure, loss of access, data corruption, security incident and workforce disruption in continuity planning. Customers remain responsible for exporting or retaining information they need to satisfy their own continuity, legal and recordkeeping obligations.

Personnel and contractors with access to Acuity information are subject to confidentiality obligations appropriate to their role. Access to Customer Content is limited to legitimate support, security, maintenance, legal or service-delivery purposes.

Personnel receive security and privacy guidance relevant to their responsibilities. People with elevated or specialised duties may receive additional training on topics such as secure development, incident handling, payment data, privacy requests or provider rules.

Workforce access must be authorised, traceable and limited to the minimum reasonably required. Unauthorised browsing of Customer Content, credential sharing and use of production data for unrelated personal purposes are prohibited.

Acuity assesses service providers according to the service, access, data, location and risk involved. Review may include security and privacy information, contractual terms, data-processing commitments, incident history, access method, deletion capability and relevant independent assurance.

Providers that process confidential information for Acuity are required to protect it and use it only for authorised purposes through contractual, technical or organisational controls appropriate to their role. Acuity seeks to limit provider access to the data and duration necessary for the service.

Acuity maintains a register of subprocessors that may process Customer personal data on Acuity's behalf. The live register identifies the legal provider, service and purpose, relevant data categories, primary processing locations and transfer safeguards known to Acuity. The live website version is authoritative and is updated before or in connection with a material new subprocessor use as required by the DPA.

Customers may request the current register or prior change information at support@acuityintelligence.io with the subject "Subprocessor Request". Where an applicable DPA provides a notice or objection right, Acuity will follow that process. An objection must be based on reasonable data-protection grounds and must be submitted within the period stated in the DPA.

Stripe provides supported payment-processing and related billing services. Stripe may act independently for payment, fraud prevention and legal compliance and is not represented as an Acuity subprocessor for every payment activity.

Google, Microsoft, LinkedIn, Meta, HubSpot, Xero and similar platforms may be Connected Services selected and authorised by a Customer. A provider is not an Acuity subprocessor solely because a Customer directs Acuity to connect to that provider. The provider's own terms and privacy notice apply to its independent platform.

Acuity reviews the public register against its approved production inventory for hosting, database, identity, AI or model services, analytics, support, communications, monitoring and payment when a material architecture or provider change occurs. Acuity will not knowingly describe an incomplete provider list as comprehensive. Questions or suspected omissions may be reported to support@acuityintelligence.io.

Provider locations and transfer safeguards are addressed in the live register, Privacy Policy and DPA. Acuity uses contractual and other lawful safeguards appropriate to the relevant transfer and jurisdiction.

Supported card payments use Stripe-hosted or Stripe-provided interfaces so sensitive card data is sent directly to Stripe rather than through Acuity's ordinary application fields. Acuity may receive tokens and limited transaction metadata needed for billing, support, fraud management, accounting and legal compliance.

PCI DSS applies to organisations that store, process or transmit cardholder data. Stripe is responsible for the security and validation of its environment. Acuity remains responsible for its own merchant environment, integration choices, access controls, web security and the applicable validation or attestation. Stripe's certification does not certify Acuity.

Users and personnel must not send complete card numbers, card-security codes, magnetic-stripe data, chip data or PIN data through Customer Content, email, chat, logs or support tickets. If such data is received unexpectedly, Acuity will restrict access and handle it under the incident and deletion process.

Payment webhooks and administrative actions should be authenticated, authorised, logged and limited to the minimum event and metadata needed. Secrets are treated as restricted information and rotated if compromise is suspected.

Acuity generally acts as a processor, data intermediary, service provider or contractor when it processes Customer Content on a business Customer's documented instructions. The Customer determines the purpose, lawful basis, submitted data, users and authorised actions. Acuity acts independently for its own account, security, billing, support and legal-compliance processing as described in the Privacy Policy.

The current DPA is available to eligible business Customers through Acuity's contracting process or by emailing support@acuityintelligence.io with the subject "DPA Request". The DPA is separately versioned and should be accepted or signed by an authorised representative.

The DPA addresses documented instructions, processing details, confidentiality, security, subprocessors, individual-rights assistance, impact assessments, regulator cooperation, personal-data incidents, audits, return or deletion, international transfers, liability and precedence.

Eligible Customers may request available security or privacy information reasonably needed for vendor due diligence. Acuity may require confidentiality, limit disclosure of sensitive security information and use standard materials or questionnaires where they are sufficient.

Acuity may use AI-assisted systems to analyse retrieved evidence or Customer Content, classify information, identify patterns, summarise material, generate recommendations or drafts, and prepare a workflow or action for review. A feature's interface and Documentation describe its intended purpose.

Inputs may include a submitted domain, public website evidence, Customer prompts, workspace content, connected data, configuration and user feedback. Outputs may include summaries, scores, classifications, explanations, drafts and proposed actions. The exact data depends on the enabled feature and permissions.

Acuity may use approved model or infrastructure providers to deliver an AI feature. Provider access, retention and training settings must be reviewed before production use and reflected in the DPA and provider register where applicable. Customer Content is not authorised for general-purpose model training unless the Customer expressly agrees through an approved contractual or product control.

An AI feature does not expand a user's role or Connected Service permission. Access to data and tools remains limited by workspace authorisation, provider scopes and feature controls. A proposed outbound action must remain within those boundaries.

AI Output may be inaccurate, incomplete, outdated, biased or unsuitable. Users must review material Output, evidence, recipients, assumptions and consequences. Consequential actions remain subject to appropriate human approval unless the Customer has expressly configured a supported and lawful automation.

Acuity is not designed to replace professional judgement and must not be used as the sole basis for employment, credit, insurance, housing, healthcare, education, legal or similarly high-impact decisions unless the specific use is expressly supported, contractually agreed, lawfully assessed and subject to effective human oversight.

Where supported, users can edit, reject or correct an Output before action. Concerns about an AI result, unsafe behaviour or inability to challenge an outcome may be reported to support@acuityintelligence.io with the subject "AI Concern". Acuity may request relevant prompts, Output, context and account details while asking the reporter to minimise personal data.

Material AI features should be recorded in an internal inventory with a purpose, owner, provider, data categories, permissions, evaluation evidence and risk assessment. Changes that materially affect behaviour, providers, data use or human control require review before production release.

Acuity is committed to making its public website and core Service journeys usable by people with disabilities. Acuity targets the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA as its product and content benchmark.

The target is a design and testing commitment, not an unsupported certification. Acuity will describe a page or journey as conformant only after appropriate automated and manual evaluation. Until a complete production evaluation is approved, Acuity does not claim full-site WCAG 2.2 AA conformance.

Material public and product journeys should be evaluated for keyboard access, visible focus, headings and landmarks, form labels and errors, zoom and reflow, colour contrast, screen-reader behaviour, target size, accessible authentication, motion and other applicable WCAG criteria. Automated testing is supplemented by manual review because automated tools do not identify every issue.

Acuity aims to support current versions of widely used browsers and assistive technologies. Exact compatibility depends on the released application and should be documented after testing. Older or unsupported browser and assistive-technology combinations may not receive the same experience.

If you encounter a barrier or need information in an alternative format, email support@acuityintelligence.io with the subject "Accessibility" and describe the page, task, technology used and preferred assistance. Do not include sensitive information that is not needed to resolve the issue.

Accessibility reports are triaged according to impact, frequency and availability of a workaround. Acuity will aim to provide practical assistance while a fix is assessed. Response or remediation timing depends on severity and complexity unless a contract or applicable law requires a specific period.

Acuity welcomes good-faith reports that help protect Customers, users and the Service. This section explains how to test and report responsibly. It is not an invitation to access data, disrupt systems or test third-party services without permission.

The following are in scope only to the extent they are owned or operated by Acuity and publicly accessible:

• acuityintelligence.io and Acuity-controlled subdomains;
• Acuity production web applications and APIs that link to this policy; and
• authentication, authorisation, tenant separation, data exposure and integration behaviour directly controlled by Acuity.

The following are out of scope unless Acuity gives written permission:

• third-party platforms, cloud providers, Connected Services and payment systems;
• Customer-controlled domains, accounts, content, devices or networks;
• employee, contractor or personal devices and accounts;
• physical offices and facilities;
• denial-of-service, load, stress or resource-exhaustion testing;
• social engineering, phishing, bribery, threats or impersonation;
• automated scanning that materially degrades service or ignores rate limits; and
• reports that only identify missing best-practice headers or software versions without a demonstrable security impact.

To qualify as good-faith research, you must:

• test only accounts, workspaces and data you own or have explicit permission to use;
• minimise requests, automation, access and retained data;
• stop immediately if you encounter personal data, credentials, Customer Content or evidence of cross-customer access;
• do not download, copy, alter, delete or disclose data beyond the minimum evidence needed;
• do not maintain persistence, move laterally, access another account, or use a vulnerability for profit or leverage;
• give Acuity a reasonable opportunity to investigate and remediate before public disclosure; and
• comply with law and this policy.

Do not perform denial of service, destructive testing, data exfiltration, privacy intrusion, malware deployment, credential attacks, social engineering, physical attack, spam, extortion or threats. Do not access or modify another person's data. If proof requires more than minimal validation, stop and ask Acuity for written authorisation.

Email support@acuityintelligence.io with the subject "Vulnerability Report". Include:

• the affected URL, feature, API or component;
• the date and time observed and your test account, if relevant;
• clear reproduction steps and the minimum proof needed to show impact;
• the potential confidentiality, integrity, availability or tenant impact;
• any temporary mitigation you recommend; and
• a safe way to contact you.

Do not attach unnecessary Customer data, secrets or executable malware. If sensitive material is needed, ask for an approved secure transfer method before sending it.

Acuity aims to acknowledge a useful report promptly, triage it according to risk and provide updates when there is material progress. Complex issues, third-party dependencies and incomplete reports may require more time. Acuity will coordinate disclosure in good faith but does not promise a fixed remediation or publication date.

If you comply with this policy and act in good faith, Acuity will not initiate legal action against you solely for the authorised research described here. If a third party initiates action and Acuity is aware that you complied with this policy, Acuity may state that your activity was conducted under this policy. This safe harbour does not authorise violations of law, bind third parties or authorities, or protect activity outside this scope.

Acuity does not currently operate a public bug-bounty or guaranteed reward programme. A report does not create a right to payment, recognition, employment or other compensation. Acuity may acknowledge a researcher only with the researcher's consent and after the issue is safely resolved.

Acuity should publish an RFC 9116-compatible file at https://acuityintelligence.io/.well-known/security.txt containing the monitored contact, canonical policy URL, expiry date and preferred language. The file must be reviewed and renewed before expiry.

Acuity lists only current assurance that applies to the identified entity, Service, system and period. Internal testing, an independent assessment and a formal certification are different and will be labelled accordingly.

A provider's SOC, ISO, PCI DSS or other certification covers the provider's stated scope. It does not automatically certify Acuity or every Acuity configuration. Acuity will not use a provider badge or report to imply broader assurance.

Unless a dated assurance item is expressly listed in the live version of this section, Acuity makes no public claim that the Service is SOC 2 attested, ISO/IEC 27001 certified, independently penetration tested or subject to a guaranteed uptime or data-residency commitment.

Eligible Customers may request available security information at support@acuityintelligence.io with the subject "Security Review". Acuity may provide standard responses, current evidence or a confidential review under appropriate restrictions.

Use support@acuityintelligence.io and include one of the following subject labels so the request can be routed appropriately:

• "Security Question" for general security enquiries;
• "Security Incident" for suspected compromise;
• "Vulnerability Report" for good-faith research;
• "Privacy Request" for personal-data rights;
• "DPA Request" for the Data Processing Addendum;
• "Subprocessor Request" for provider information or notices;
• "AI Concern" for an AI result or control concern; or
• "Accessibility" for assistance or an alternative format.

ACUITY INTELLIGENCE SG PTE. LTD.

Singapore UEN 202633032N

68 Circular Road, #02-01, Singapore 049422

support@acuityintelligence.io

The Global Privacy Policy is available at /legal/privacy. The Terms & Conditions are available at /legal/terms. The live DPA and subprocessor materials are available through the process described in sections 13 and 15.

"Planned" means approved for future implementation but not operating. "In progress" means implementation or validation is underway. "Implemented" means the accountable owner has confirmed that the control operates for the stated scope. "Independently assessed" means a qualified external party evaluated the identified scope and period. "Certified" means an authorised certification body issued a current certification for the named entity and scope.

• Contact: mailto:support@acuityintelligence.io
• Expires: 2027-08-18T00:00:00Z
• Preferred-Languages: en
• Canonical: https://acuityintelligence.io/.well-known/security.txt
• Policy: https://acuityintelligence.io/legal/security#responsible-vulnerability-disclosure

This statement is reviewed quarterly and after a material security, provider, AI, accessibility or product change. Acuity must maintain an evidence owner for each implemented claim, reconcile the public provider register against production, test the vulnerability-reporting route and security.txt file, validate Stripe and merchant PCI responsibilities, review AI provider settings and human controls, and record accessibility testing and remediation.