Skip to content
ProductHow it worksSecurityPricing
Sign in Book a demo
ProductHow it worksSecurityPricing Sign in Book a demo
Appearance

Procursea Ltd

Information Security Policy

How we protect the confidentiality, integrity and availability of the information we hold


Effective date: 24 August 2026 Last updated: 24 August 2026 Version: 1.1

1. Purpose and scope

1.1 This policy establishes how Procursea protects the confidentiality, integrity and availability of the information it holds, including the personal data and commercial data entrusted to it by customers.

1.2 This policy applies to the Procursea web application at procursea.app, the marketing website at procursea.com, all supporting infrastructure and third-party services, and all personnel with access to production systems or customer data, including employees, contractors and consultants.

1.3 The structure and control areas of this policy are drawn from ISO/IEC 27001 Annex A and the SOC 2 Trust Services Criteria. Procursea is not currently certified against either standard, and nothing in this policy should be read as a claim of certification. The frameworks are used as a design reference for the controls described below.

2. Policy statement and objectives

2.1 Procursea is committed to protecting information assets against unauthorised access, disclosure, alteration, loss and destruction.

2.2 Our security objectives are to ensure that customer data is accessible only to those authorised to see it; that data is accurate and protected from unauthorised modification; that the platform is available to customers when needed; that we meet our legal and regulatory obligations under UK GDPR and the Data Protection Act 2018; and that security incidents are detected, contained and remediated promptly.

2.3 Security is treated as a design requirement of the platform, not as a control applied afterwards.

3. Roles and responsibilities

3.1 The Founder holds overall accountability for information security, owns this policy, approves exceptions, and acts as Incident Response Lead.

3.2 The Technical Lead is responsible for implementing and maintaining technical controls, managing production access, applying security patches, and reporting suspected incidents.

3.3 All personnel are responsible for complying with this policy, protecting the credentials issued to them, and reporting suspected security incidents without delay.

3.4 Contractors and consultants with access to production systems or customer data are bound by written confidentiality obligations and by this policy.

4. Risk management

4.1 Procursea maintains a view of the security risks affecting the platform, covering the loss or disclosure of customer data, compromise of authentication credentials or third-party access tokens, unavailability of the platform or its hosting providers, and failure or compromise of a third-party processor.

4.2 Risks are reviewed at least annually and whenever a material change is made to the architecture, a new data category is introduced, or a new third-party processor is engaged.

4.3 Identified risks are treated by applying controls, transferring the risk, or by formal acceptance recorded by the policy owner. Risk acceptance is a decision of the Founder and is documented.

5. Information classification and handling

5.1 All information held by Procursea is classified into one of four protection levels. Every data category is assigned exactly one level. Where a record contains fields of differing levels, the record is handled at the highest level present.

5.2 The four protection levels are:

  • Restricted. Disclosure, alteration or loss would cause severe harm to a user or to the business, or would constitute a personal data breach presenting a high risk to the rights and freedoms of individuals. Data at this level is encrypted at the application layer in addition to encryption at rest, is never written to application logs or error traces, is never transmitted to any third party other than the provider the data originates from, and is accessible only to the authenticated owning user and to named administrators with a documented operational need.
  • Confidential. Disclosure, alteration or loss would cause material commercial, legal or reputational harm, or would constitute a personal data breach. Data at this level is encrypted in transit and at rest, is governed by role-based access control and enforced tenant separation, and is visible only to authorised users within the owning tenant.
  • Internal. Not intended for public release. Limited harm would result from disclosure. Data at this level is encrypted in transit and at rest, and access requires authentication and is subject to role-based access control.
  • Public. Created and approved for publication. No confidentiality controls apply. Integrity controls apply: changes are made only through the normal publication process.

5.3 The following categories are classified as follows:

  • Account and identity data. User password hashes and session identifiers are Restricted. User names, email addresses, job roles, department permissions and vessel assignment are Confidential.
  • Email OAuth tokens. Google and Microsoft access tokens, refresh tokens and associated expiry metadata are Restricted.
  • Email thread content. Message content retrieved from a connected Google or Microsoft mailbox is Restricted at the point of retrieval, as it constitutes provider user data subject to the providers’ limited use requirements. Where quotation, pricing or invoice data is extracted from that content and written into a procurement record, the resulting commercial record is Confidential.
  • Payment data. Cardholder data is not held by Procursea at any time; payment collection is performed entirely by Stripe. Stripe customer and subscription identifiers, billing contact details and transaction history retained by Procursea are Confidential.
  • Operational vessel data. Inventory records, part numbers, stock levels, storage locations, requisitions, maintenance history and uploaded photographs are Internal. Vessel identity, including yacht name, registration and management company, is Confidential, reflecting the commercial sensitivity of vessel ownership in the superyacht industry.
  • Vessel general arrangement plans. Uploaded general arrangement plans, and the physical locations of inventory items marked upon them, are Confidential. These records describe the internal layout of a vessel, including crew and owner accommodation and the position of safety equipment.
  • Application logs and telemetry. Internal. Logs are configured not to contain credentials, access tokens, mailbox content or complete personal records.
  • Published content. Material published on procursea.com, including the Privacy Policy and this policy, is Public.

5.4 Any new data field introduced to the platform must be assigned a protection level before it reaches production. Where a new field does not fall clearly within an existing category, the higher of the two candidate levels applies until the classification is formally reviewed.

5.5 Production data classified Restricted or Confidential must not be copied into development or testing environments. Synthetic or anonymised data is used for development and testing.

6. Access control

6.1 Access to systems and data is granted on the principle of least privilege. Personnel receive only the access required to perform their role.

6.2 Within the application, access is governed by role-based access control. Each user holds a job role which maps to one of four permission tiers: captain, head of department, crew, or management company. The tier determines which capabilities a user holds, including creating requests for quotation and purchase orders, managing inventory, managing crew, and viewing billing. Independently of tier, each user is granted view, edit or manage permission per operational department, and users without vessel-wide scope can act only within the departments assigned to them. A small number of senior crew roles are granted additional capabilities beyond the crew tier default; these exceptions are defined in code and reviewed when the role model changes. Every data query is scoped to the vessel the user is assigned to, so that users associated with one vessel cannot access data belonging to another.

6.3 User passwords are subject to a minimum length requirement enforced at account activation, password reset and password change. Passwords are hashed using bcrypt with a per-password salt and are never stored, transmitted or logged in reversible form.

6.4 Session identifiers are regenerated on authentication. Sessions are terminated on sign-out and expire after a period of inactivity.

6.5 Access to production systems is reviewed at least every six months, and is revoked immediately when a person’s role changes or their engagement ends.

6.6 Shared or generic accounts are not used for administrative access. Each administrator holds an individually identifiable account.

6.7 Accounts are created in an inactive state and are activated only when the user sets their own password using a single-use, time-limited activation link. Initial system-generated secrets are never disclosed to any party and cannot be used as a long-term password.

7. Cryptography and key management

7.1 All data in transit between users and the platform, and between the platform and its third-party services, is protected using TLS 1.2 or TLS 1.3. Connections to the database require SSL/TLS.

7.2 All data at rest in the production database and in backups is encrypted using AES-256 by the hosting provider.

7.3 Data classified Restricted is additionally encrypted at the application layer before storage. Third-party mailbox tokens are encrypted using AES-256-GCM with a cryptographically random initialisation vector generated per record, and an authentication tag that is verified on decryption.

7.4 Encryption keys and other secrets are held in the platform secret store and are not present in source code, configuration files committed to version control, or documentation.

7.5 Credentials that expire, including third-party application client secrets and certificates, are tracked with their expiry dates and renewed before lapse.

8. Personnel security

8.1 All personnel with access to customer data are bound by written confidentiality obligations that survive the end of their engagement.

8.2 Access is provisioned only after the need is established, and is revoked on the last day of engagement.

8.3 Personnel are briefed on this policy, on the classification scheme in section 5, and on the incident reporting process, before being granted production access.

9. Third-party and supplier security

9.1 Procursea relies on the following third-party processors:

  • Stripe — payment processing
  • Neon — managed PostgreSQL database hosting
  • Replit — application hosting and deployment
  • Cloudinary — media storage
  • Resend — transactional email delivery
  • Apple — map rendering and location search within the supplier directory
  • Microsoft and Google — optional mailbox integration
  • OpenAI, Anthropic and Google — AI-assisted item identification and document extraction

9.2 Before a new processor is engaged, its security posture, published certifications, data processing terms and processing locations are assessed, and the processor is added to the sub-processor list published in the Privacy Policy.

9.3 Processors are engaged under written terms that impose confidentiality and security obligations consistent with UK GDPR Article 28.

9.4 Content retrieved from a connected Google or Microsoft mailbox is not transmitted to any AI provider.

9.5 The sub-processor list is reviewed at least annually.

10. Secure development

10.1 Security requirements are considered at design stage for new features, with particular attention to authentication, authorisation, tenant separation, and the classification of any new data field.

10.2 Code changes are reviewed before deployment to production.

10.3 Secrets are never committed to source control. The source repository is private.

10.4 Third-party dependencies are monitored for known vulnerabilities and updated on a risk-prioritised basis.

10.5 Application source, configuration and dependency manifests are held under version control. Deployment to production is automated and repeatable from the version-controlled main branch, and produces an equivalent environment on each run.

10.6 The platform is assessed against the Cloud Application Security Assessment framework, which is based on the OWASP Application Security Verification Standard. Findings are remediated and revalidated before the assessment is closed.

11. Operations security

11.1 Application and infrastructure events are logged, including authentication events, permission changes and administrative actions. Logs are protected against unauthorised modification.

11.2 Changes to production are deployed through a controlled process. Changes are tested before release and can be rolled back.

11.3 Backups of the production database are taken automatically by the hosting provider, encrypted at rest, and retained on a rolling basis for up to ninety days.

11.4 Restoration from backup is tested periodically to confirm that backups are usable.

12. Physical security

12.1 Procursea does not operate its own data centres or server infrastructure. All production systems are hosted by third-party cloud providers, and physical and environmental security is the responsibility of those providers under their own certified control frameworks.

12.2 Personnel devices used to access production systems must be protected by full-disk encryption, a screen lock, and current operating system security updates.

13. Vulnerability management

13.1 The platform is subject to periodic security assessment, including automated scanning of the production application.

13.2 Identified vulnerabilities are assessed for severity and remediated on a risk-prioritised basis. Critical and high severity findings are prioritised for immediate remediation.

13.3 Procursea operates a Vulnerability Disclosure Policy setting out how security researchers may report suspected vulnerabilities and how Procursea will respond.

14. Incident management

14.1 A security incident is any actual or suspected event that compromises, or may compromise, the confidentiality, integrity or availability of information held by Procursea.

14.2 All personnel must report suspected incidents to the Incident Response Lead without delay.

14.3 Incidents are handled in accordance with the Procursea Incident Response Policy, which covers detection, triage, containment, eradication, recovery, notification and post-incident review.

14.4 Where an incident constitutes a personal data breach under UK GDPR, Procursea will notify the Information Commissioner’s Office without undue delay and, where feasible, within 72 hours of becoming aware of it, and will notify affected individuals where the breach is likely to result in a high risk to their rights and freedoms.

14.5 Where an incident affects customer data, affected customers will be notified in accordance with our contractual obligations.

15. Business continuity

15.1 Procursea maintains the ability to restore service following a significant disruption, relying on the redundancy and backup capabilities of its hosting providers.

15.2 Continuity arrangements are reviewed at least annually.

16. Compliance

16.1 Procursea processes personal data in accordance with UK GDPR and the Data Protection Act 2018, and, where applicable, the EU GDPR. Processing activities, lawful bases and retention periods are described in the Privacy Policy.

16.2 Procursea does not store cardholder data. Payment collection is performed by Stripe, and the scope of card data handling therefore sits with Stripe rather than with Procursea.

16.3 Where a customer requires a Data Processing Agreement under UK GDPR Article 28, one is executed before processing begins.

17. Policy review and exceptions

17.1 This policy is reviewed at least annually by the document owner, and additionally following any significant security incident, material change to the platform architecture, engagement of a new processor, or change in applicable law.

17.2 Exceptions to this policy require the written approval of the policy owner, must be time-limited, and must record the compensating controls applied.

17.3 Failure to comply with this policy may result in withdrawal of access and, for personnel, disciplinary or contractual consequences.

18. Related documents and contact

This policy should be read alongside the Procursea Privacy Policy and the Terms of Service.

Procursea Ltd
United Kingdom
Email: info@procursea.com

Copyright © 2026 Procursea Ltd. All rights reserved.

Procursea

Serious procurement software, purpose-built for superyachts.

Sign in

Product

  • Platform
  • Ai Procurement
  • Visual Scan
  • Supplier Network
  • Mobile App

Company

  • Pricing
  • Contact

Resources

  • How it works
  • FAQ
  • Tutorials

Legal

  • Privacy
  • Terms
  • Cookies
  • Information Security
  • Vulnerability Disclosure

Network

  • Supplier Network Coming soon
  • A new procurement network connecting marine suppliers with the vessels they serve.
Download on the App Store

Copyright © 2026 Procursea Ltd. All rights reserved.

Monaco · Antibes · Palma

Cookies

We use no tracking or analytics cookies. The interactive demo is hosted by Appetize, which sets its own cookie when you choose to load it. No tracking or analytics. The demo sets a third-party cookie if you load it. Cookie Policy