Security Standards

At ProcureLabs, security is fundamental to our platform. This page describes the measures in place to protect your procurement data, and what they do and do not cover.

Certifications Compliance

Data Encryption

Infrastructure Security

• Cloud Infrastructure: Hosted on AWS, which holds SOC 2, ISO 27001 and PCI DSS certifications. These are AWS's certifications, not ProcureLabs'.
• Data Isolation: Row-level security is enabled on the database tables that hold customer data, so a signed-in user's queries return only their own organization's rows. Background jobs and administrative paths that run with elevated database access do not pass through row-level security; they apply the tenant filter in application code.
• Availability: Single AWS region (Singapore); no cross-region failover
• Disaster Recovery: Database backups with point-in-time recovery, provided by our database host (Supabase)

Access Control

Security Monitoring & Response

• Vulnerability Management: Every merge request is scanned for committed secrets (Gitleaks) and fixable critical dependency vulnerabilities (Trivy).
• Incident Response: Incidents are handled by ProcureLabs' founder using the platform's incident-response playbooks, and affected customers are notified by email.
• Security issues can be reported to our security contact below.

AI Data Processing Security

Our AI features are designed with security and privacy in mind:

• OpenAI processing OpenAI supports chat, analysis and bounded Decisions judgements for tool selection and procurement evidence. Subject to current customer permission and the agreed regional configuration, Decisions receives minimised, redacted context and questions for the permitted purpose. OpenAI API data is not used for model training unless explicitly opted in. Decisions can retain encrypted prompt-cache state for up to 24 hours and standard abuse-monitoring logs for up to 30 days, subject to applicable security, safety or legal exceptions.
• Permission for Decisions processing Decisions processing requires current customer instructions and permission for the specific purpose, account, processor and US transfer. Disabling AI or withdrawing the applicable authority prevents new Decisions requests. Consequential actions remain subject to the required safeguards and independent review.
• Retention follows the applicable data category, customer instructions, legal holds and provider terms. Chat history, derived content, audit records and provider logs have separate retention conditions. Deletion requests are handled under the DPA and applicable law.
• Optional AI features can be disabled by administrators
• AI features can be switched off for the whole organisation by an administrator, or by each user for themselves
• Audit log of decisions on AI-proposed actions

Data Residency

All customer data is stored in a single region. AI features process the data they need with AI providers in the United States. Additional storage regions are not available today.

Governance

• We keep a written information security policy, with an index of our policies and procedures, reviewed at least annually.
• We keep a written code of conduct covering honesty, confidentiality and conflicts of interest.
• ProcureLabs has three founders. David Hodge, CEO and Director, is accountable for security and data protection. Cofounder review and independent recovery arrangements are being documented and verified.
• We keep a written risk register, reviewed at least annually and before significant changes.
• We keep a written process for checking and reviewing our sub-processors. Physical security of the servers that run ProcureLabs is provided by AWS and Supabase; we operate no data centres of our own.
• We keep a written business continuity plan, reviewed at least annually.
• We have a written procedure for test-restoring our database from backup. A database-only restore exercise has been completed and the temporary copy removed. Full application, authentication and object-storage recovery, and independent alternate-operator access, remain to be verified.

Change management and processing integrity

• Code changes reach our main branch through merge requests that must pass required pipeline checks, including secret scanning, database-migration checks and a check that the security and privacy statements on this site still match the code. Production is released only from that branch. An automated test fails if a required check is removed or allowed to fail.
• Known weaknesses in the code are recorded, in baselines and in our compliance evidence register. A change that adds a new one, such as an error handler that silently discards an error or a published statement whose supporting code has changed, is blocked until it is fixed or recorded.
• Most write endpoints in our API check each request body against a declared schema and refuse a request that does not match with a 400 error.
• Each run of our detection engines records, for every detector, whether it completed and how many results it returned, or that it failed. A failure is recorded as a failure, never as “no findings”.