Security Policy

Last updated: 01 September 2026

Protecting Customer Data is central to how Kroolo builds and runs its Services. This policy describes the security measures Kroolo maintains for Kroolo Work, Kroolo Search, Kroolo AI, our apps and our Sites. It is referred to in Section 12.3 of our Terms of Service and applies alongside our Privacy Policy and Data Processing Addendum. Security is shared: Kroolo secures the platform, and Customers secure how they use it (Section 12). Capitalized terms have the meaning given in the Terms.

1. Scope and approach

1.1 Scope. This policy covers the systems, people and processes Kroolo uses to provide the Sites and Services and to protect Customer Data.

1.2 Shared responsibility. Kroolo is responsible for the security of the platform, including infrastructure, application code and the safeguards in this policy. Customers are responsible for how they configure and use the Services, including Users, permissions, authentication, Connectors and the data they submit (Section 12).

1.3 Commitment and changes. We may update these measures as threats and technology change, but we will not materially reduce the overall protection of Customer Data during a Subscription Term. An Order Form or enterprise agreement may add commitments. Where it conflicts with this policy, it prevails, as Terms 1.6 describes.

2. Governance and assurance

2.1 Ownership. Responsibility for security rests with Head of DevSecOps. Every employee, contractor and temporary worker with access to Kroolo systems is responsible for following our security policies. Audit and test findings are reported to executive management.

2.2 Policies and risk management. We keep written security policies and review them at least annually. We assess security risks on a recurring basis, rate them, and track mitigation to completion under ISO 27001.

2.3 Independent assurance. We engage independent third parties to assess our controls, and we track their findings to resolution.

3. Infrastructure and hosting

3.1 Cloud provider. Kroolo runs on Amazon Web Services. AWS is responsible for the physical and environmental security of its data centers, and we rely on its controls for that layer.

3.2 Location and resilience. Customer Data is stored in AWS region US East (N. Virginia). We use serverless and managed AWS services to keep the Services available. If you need a different hosting region, tell us; regional hosting is available only where an Order Form says so. Cross-border transfers are covered in Section 8 of the Privacy Policy.

3.3 Network security. Our firewalls deny inbound traffic by default, and we review firewall rules at least annually. A web application firewall and content delivery network protect against common web attacks, including denial-of-service attacks.

3.4 Environments and configuration. Production is separated from development and test environments. Customer Data is not used in development or test systems. We document the configuration of our systems and approve changes to it.

4. Data protection

4.1 Encryption. Data in transit is encrypted with TLS 1.2 or higher, and TLS 1.3 where the client supports it. Data at rest is encrypted with AES-256 at the storage layer. Database connections are verified with certificates and encrypted.

4.2 Key management. Encryption keys are managed in AWS key management services. Access to keys is limited to authorized personnel and requires multi-factor authentication. Key use is logged and monitored for unusual activity, and keys are rotated at least annually.

4.3 Credentials and tokens. Passwords we store are protected with salted one-way hashing. Tokens used for integrations are stored encrypted.

4.4 Tenant separation. Each Customer’s data is logically separated from other Customers’ data, and access checks are applied to requests.

4.5 Retention, deletion and backups. We keep Customer Data during the Subscription Term. After it ends, Customer Data is available read-only for export for at least 30 days and is deleted from active systems within 90 days, as Terms 6.8 states. Backups are overwritten on our normal cycle. AWS sanitizes storage media before it leaves its control, using techniques consistent with NIST SP 800-88.

4.6 Access by Kroolo personnel. Kroolo personnel access Customer Data only to give support, respond to incidents, or keep the Services secure, as Terms 6.6 describes. Access is from company-managed devices, lasts no longer than the task needs, and is logged.

5. Access control

5.1 Least privilege. We grant access on the principles of least privilege and role-based access, so people can reach only what their job requires.

5.2 Authentication. Access to production infrastructure, supporting systems, source code and encryption keys requires multi-factor authentication.

5.3 Reviews. We review user access, including production access, at least semi-annually.

5.4 Leavers and role changes. We revoke a leaver’s access by the end of the same business day, and immediately in an involuntary termination. A change of role triggers an access review.

6. Secure development and vulnerability management

6.1 Secure development. Our development lifecycle includes peer code review. Code is kept in version control with branch protection, and access to source code requires multi-factor authentication. [Automated code and dependency scanning runs on every change.] We review the open-source components we adopt.

6.2 Change management. Standard changes follow our release process. Emergency changes and hotfixes follow a documented change management process, and teams deploy improvements continuously.

6.3 Vulnerability scanning. We scan in-scope systems for vulnerabilities daily.

6.4 Remediation targets. We remediate vulnerabilities according to severity.

6.5 Penetration testing. An independent third party performs network and application penetration tests at least annually. We track findings to resolution and report them to executive management. A summary is available to customers under NDA on request.

7. AI and search security

7.1 Model providers. AI Features use third-party model providers as our subprocessors, under written terms. We send a provider only the content the feature needs. We do not use Customer Data to train AI models, and we require providers not to do so.

7.2 Permission-aware retrieval. Kroolo Search is designed to enforce each source’s access permissions when a query runs, so a User sees only content that User can already access at the source. The search index is access-controlled and encrypted.

7.3 Connectors. Connectors use OAuth and request only the scopes the enabled features need. Access tokens are stored encrypted. Users and Admins can revoke access, and Admins can disable Connectors. Our use of Google data follows the limits in Section 6.6 of the Privacy Policy.

7.4 AI Agents and automation. Agent actions are limited to the permissions granted to the User or Admin who set them up.

7.5 AI-specific threats. We assess risks such as prompt injection, data leakage and misuse, and apply mitigations including permission checks, least-privilege access for tools, and input and output controls. AI output can still be wrong, so Customers should review it before relying on it.

7.6 Logging. We log AI Feature requests to detect abuse and security incidents, and we keep prompt content no longer than needed for that purpose.

8. Monitoring and incident response

8.1 Logging and monitoring. Centralized logging is enabled for all production systems. We review logs for signs of compromise and alert on them. The security team tracks security events to resolution under the incident response plan.

8.2 Incident response plan. We maintain a documented plan that covers preparation, identification, containment, eradication, recovery and post-incident review. We test it at least annually.

8.3 Customer notification. If we confirm a breach of security that leads to unauthorized access to, or loss of, Customer Data, we will notify affected Customers without undue delay. The notice will describe what happened, the likely impact, what we are doing, and what we recommend Customers do. We will keep Customers updated and provide a post-incident summary on request.

9. Resilience and continuity

9.1 Availability. We design the Services to keep running through the failure of individual components. Current status is published at kroolo.statuspage.io.

9.2 Backups and recovery. These are our targets, not guarantees, unless an Order Form says otherwise.

9.3 Business continuity. We maintain a business continuity plan, our staff can work remotely if an office is unavailable, and we communicate during major incidents through the status page and email.

10. People and endpoints

10.1 Screening and confidentiality. New employees complete a background check before they start, where the law permits, and sign confidentiality agreements.

10.2 Training. All employees complete security awareness training when they join and annually after that. It covers phishing, remote-work practices, device security and incident reporting. Employees also review the employee handbook and code of conduct. Violations of policy may lead to disciplinary action, up to and including termination.

10.3 Endpoints. Employees use company-managed workstations with disk encryption, anti-malware protection and idle lockout. IT monitors that workstations comply with policy and are patched.

11. Vendors and subprocessors

11.1 Vendor review. We review vendors that handle Customer Data before we engage them and at least annually. Contracts include confidentiality, security and data protection terms.

11.2 Subprocessors. We publish our subprocessors and notify Customers of changes as the DPA requires.

12. Customer responsibilities and controls

12.1 What Customers control. Customers are responsible for:

• managing Users, roles, permissions and guests, and removing access promptly when people leave;
• strong authentication, including single sign-on and multi-factor authentication where available, and protecting the credentials of any email and password sign-ins;
• the security of their own devices and connected systems;
• configuring Connectors with least privilege, and keeping permissions in source systems correct, because Kroolo Search shows only what the source permits;
• deciding what data to submit. Do not submit payment card data. Protected health information is permitted only under a signed business associate agreement. Other restricted data is governed by Terms 6.4; and

13. Compliance and customer assurance

13.1 Regulated customers. For customers in financial services and other regulated sectors, we support due diligence with responses to security questionnaires, summaries of our policies, penetration-test summaries and assurance reports under NDA. Enterprise agreements can include audit or assessment rights, and we will reasonably help with regulatory requirements on outsourcing and technology risk.

13.2 Data protection. Our handling of personal information is described in the Privacy Policy and the DPA.

13.3 Requests. Send security due-diligence requests to security@kroolo.com.

14. Reporting security issues

14.1 How to report. If you believe you have found a vulnerability, email security@kroolo.com, Include a description, steps to reproduce, the affected product or URL, and your contact details.

14.2 Ground rules. Please do not access, change or copy data that is not yours, do not disrupt the Services, and give us reasonable time to fix the issue before you disclose it publicly. We will acknowledge your report within 3 business days. If you act in good faith and follow these rules, we will not take legal action against you, as Terms 8.6 describes.

14.3 Not for support. Use kroolo.com/contact-support for account problems.

15. Changes to this policy

We may update this policy. The “Last updated” date shows the current version, and we will give notice of material changes by email or in the Service. Section 1.3 limits how far we can reduce protection during a Subscription Term.

16. Contact

• Security and due diligence: security@kroolo.com
• Privacy: privacy@kroolo.com