Security addendum

1. Security program and governance

• Security Leadership. A designated security lead oversees AcuityRFP’s information security program, security policies, vulnerability management, incident response readiness, and periodic access reviews.
• Policies and Reviews. We have written internal policies covering information security, access control, change management, incident response, vendor risk management, and data retention and disposal. They are being finalized for formal approval and will be reviewed and updated at least annually.
• SOC 2 Readiness. We maintain an internal security controls framework mapped to the AICPA Trust Services Criteria (Security, Confidentiality, and Availability) in preparation for an independent SOC 2 examination and will make our SOC 2 report available to customers under NDA once issued.

2. Multi-tenant isolation

• Database-Layer Enforcement. Every database table storing Customer Content includes an organization identifier, and PostgreSQL Row-Level Security (RLS) policies verify organization membership on every read and write operation directly inside the database engine, rather than relying solely on application-layer filtering.
• Scoped Search Queries. Semantic and keyword searches across your knowledge base and answer library are strictly scoped to your organization identifier within the database query execution plan.
• Automated Isolation Verification. Our database change process includes automated cross-tenant isolation tests that authenticate as Users across separate test organizations and verify that cross-organization read and write attempts are rejected whenever database schemas or policies are modified.

3. Encryption and data storage

• Encryption Standards. All external network traffic is encrypted in transit over HTTPS/TLS 1.2+. All database records and stored files are encrypted at rest using AES-256 encryption managed by our cloud infrastructure providers.
• Private Object Storage. Uploaded documents and generated exports are stored in non-public storage buckets and served to authenticated Users only via short-lived, cryptographically signed URLs.
• Application-Layer Encryption for Integration Tokens. OAuth access and refresh tokens for connected third-party tools (such as Google Drive, SharePoint, OneDrive, and Slack) are encrypted at the application layer using AES-256-GCM with an encryption key stored outside the database, are decrypted solely by backend worker processes, and are never transmitted to client browsers.
• Secret Management. API keys, cryptographic keys, and privileged credentials are injected solely via secure server-side environment variables and are never hardcoded in source code, written to application logs, or exposed to browsers.
• Data Residency. Customer Content is stored in the primary cloud region designated in your agreement or workspace configuration. Alternative regional hosting or dedicated database instances are available for enterprise customers upon written agreement.

4. Access control

Customer workspace controls

• Role-Based Access Control (RBAC). Four granular User roles (owner, admin, editor, and viewer) are enforced at the database layer.
• Single Sign-On (SSO). Organizations on any Plan may configure SAML 2.0 Single Sign-On (compatible with Okta, Microsoft Entra ID, Google Workspace, and other SAML 2.0 identity providers) and enforce SSO login for all Users, while preserving an owner password login for emergency break-glass recovery.
• Secure Invitations. User invitations are single-use, cryptographically bound to the recipient’s email address, and automatically expire. Accepting one requires a verified email address.
• Verified Email. Users must verify their email address before using the Service. SSO sign-ins count as verified.
• Two-Factor Sign-In. Users can protect their accounts with an authenticator app and single-use recovery codes, which are stored only as keyed hashes. Owners can require two-factor sign-in for admins or for all members. SSO sign-ins meet the requirement through the identity provider.
• Password and Sign-Up Protection. New passwords have at least 15 characters and are checked against known breached passwords without the password itself leaving our servers. Repeated failed sign-ins trigger lockouts, and sign-up includes a bot check.
• Session Controls. Sessions end after 24 hours without use and at most 14 days after sign-in. Users can see their signed-in devices, sign out any of them, and receive an email about a sign-in from a new browser or a change to their password or two-factor settings.

AcuityRFP internal access controls

• Least Privilege and MFA. All AcuityRFP personnel authenticate using named individual accounts protected by mandatory Multi-Factor Authentication (MFA) and are granted access strictly on a least-privilege basis.
• Restricted Support Access. Authorized personnel access Customer Content only when necessary to resolve a support request or technical issue, investigate a security event, or comply with applicable law, and all administrative access is logged with an auditable justification.
• Offboarding. Upon termination of employment or engagement, personnel access to all production and corporate systems is promptly revoked and any shared credentials accessible to that individual are rotated.

5. Application and network security

• Input Validation and Upload Controls. All API inputs are schema-validated at the server boundary, and strict file size and MIME-type restrictions are enforced server-side.
• HTTP Security Headers. Defensive security headers (including Content Security Policy, HSTS, X-Content-Type-Options, and frame protections) are applied across the application.
• Malicious File Filtering. Exported files are served as attachments with protective headers. Uploaded Word templates/themes are inspected prior to processing, and files containing VBA macros, ActiveX controls, or embedded OLE objects are automatically rejected.
• SSRF Protection on Website Imports. The Website Import crawler validates target URLs against Server-Side Request Forgery (SSRF) risks by resolving DNS and blocking connections to loopback, private, link-local, and cloud-metadata IP ranges both at initial connection and across every HTTP redirect.
• Webhook and OAuth Verification. Incoming requests from Slack are verified via cryptographic HMAC signatures and requests from Microsoft Teams via signed JSON Web Tokens, and OAuth connection flows use signed state parameters and browser-bound nonces (google_oauth_nonce, microsoft_oauth_nonce, slack_oauth_nonce).

6. Change management

• Pre-Release Automated Checks. Code changes undergo automated static type checking, linting, unit testing, and build verification prior to production deployment.
• Versioned Database Migrations. Database schema and security policy changes are deployed exclusively through version-controlled migration scripts that are tested against our tenant-isolation test suite.
• Review and Rollback. Production changes are reviewed and approved prior to release and support rapid rollback in the event of an anomaly.

7. AI security safeguards

• No-Training Enforcement. Customer Content is processed exclusively through commercial AI APIs bound by contractual and technical no-training commitments, with runtime configuration checks preventing the use of non-compliant endpoints.
• Data Minimization. Each AI drafting or translation request transmits only the specific questions and retrieved document excerpts required for that task.
• Prompt Isolation. Retrieved document passages and imported web pages are structured within distinct data delimiters designed to prevent indirect prompt injection.
• Log Redaction. Full document contents and raw AI prompts are never written to production application logs. Error reports are automatically stripped of request data, email addresses, tokens and quoted text before they reach our error monitoring provider, though an error message may still contain a short fragment of text.

8. Audit logging

The Service maintains an organization audit log, which Users cannot edit or delete, recording key security and operational events, including answer approvals, questionnaire exports, document downloads and deletions, User invitations and role changes, integration connections, SSO configuration updates, and Trust Center NDA acceptances and visitor downloads. Organization owners and admins can inspect the audit log directly within the application.

9. Incident response

• Incident Response Plan. We maintain a written Incident Response Plan establishing severity levels, triage workflows, containment and eradication steps, forensic preservation, and recovery procedures.
• 72-Hour Breach Notification. We notify affected customers without undue delay—and within 72 hours—after confirming a security breach affecting their Customer Content, and assist customers with required regulatory notifications in accordance with the DPA.
• Post-Incident Remediation. Following any material security incident, we conduct a root-cause post-mortem and implement corrective technical controls to prevent recurrence.
• Vulnerability Reporting. Security researchers and customers may report suspected vulnerabilities to security@example.com under our Vulnerability Disclosure Policy.

10. Vendor and Subprocessor security

Prior to engaging a Subprocessor that will handle Customer Content, we evaluate its security posture (including reviewing independent audit reports such as SOC 2 or ISO 27001 certifications), execute a written data processing agreement, verify data retention practices, and confirm that Customer Content will not be used for AI model training. We review critical Subprocessors annually and provide our current Subprocessor list to customers upon request.

11. Data retention, deletion, and environment separation

• Document Deletion. Deleting a document in the Service deletes the underlying file, extracted text chunks, and vector search embeddings from active production storage.
• Organization Deletion. Deleting an organization immediately locks the workspace and notifies all Users via email; after a 7-day grace period, all database records and stored files belonging to the organization are permanently deleted from active production systems. Error reports held by our error monitoring provider expire automatically within 90 days.
• Environment Separation. Production environments are logically separated from development and testing environments, and Customer Content is never copied into non-production environments.

12. Shared security responsibilities

Security is a shared responsibility. While AcuityRFP secures the cloud infrastructure, database isolation, and application software, Customer is responsible for: (a) managing User accounts, assigning appropriate RBAC roles, and promptly deprovisioning departing personnel; (b) safeguarding login credentials, two-factor recovery codes, and owner break-glass passwords; (c) properly configuring SAML SSO if enabled; (d) reviewing which documents are published on a public Trust Center or shared via Share Links; and (e) verifying the accuracy of all AI-generated answers before external submission.