§ STD · 01 OPERATIONAL
SOC 2
SOC 2
Operational security controls — security, availability, confidentiality, and processing integrity of customer data across the platform.
ALIGNED · TYPE II IN ROADMAP
Go Find Part Limited · gofindpart.com · security@gofindpart.com
Security · Status report Security posture and controls
| File ref | GFP-SEC-26.10 |
| Revision | 26.10 |
| Claims reviewed | 2 October 2026 |
| Next review due | 2 January 2027 |
| Live page | gofindpart.com/security/ |
Built to hold.
Not to impress.
Every transaction, every account, every byte.
Industrial supply is where a wrong part can idle a production line for a shift. The platform routing those orders needs to not flinch.
This page is the whole security posture — every control we run, the standards we're aligned to, and the gaps we're honest about. No certification-mongering. No theatre. A single page you can print. How those controls protect an order is on the trust page.
Claims last reviewed · 2 October 2026 · Rev. 26.10 · Next review due · 2 January 2027
Access token life 15 min Refresh in an HttpOnly cookie, rotated on every use.
Sign-in Passkeys WebAuthn passkeys live on every surface, plus authenticator 2FA.
Backups Restore-tested A weekly backup is verified by an actual restore before it is kept.
Staff audit log Hash-chained Append-only, checked nightly, anchored monthly.
§ INDEX · CONTROLS 01–09 JUMP TO SECTION
§ 02 · FRAMEWORKS · ALIGNMENT
Standards we align our practices with.
Where the industry converges, so do we. These aren't certifications yet — they're the control frameworks our engineering & ops decisions are measured against internally, with an active roadmap to formal audit.
§ STD · 02 MANAGEMENT
ISO
27001
27001
ISO 27001
International standard for information security management systems — policy, risk assessment, and continuous improvement of controls.
ALIGNED · CERT. IN ROADMAP § STD · 03 DATA · LEGAL
GDPR
GDPR
EU & UK GDPR compliance — lawful basis, data minimisation, subject-access, retention & deletion. Enforced at the platform level, not bolted on.
COMPLIANT · ONGOING!
Transparency note · Certification status
GoFindPart is not currently certified for SOC 2 or ISO 27001. These represent standards we design against and are actively working towards. We would rather tell you the true state of our security posture — and what we're doing to improve it — than sticker-badge a page and hope you don't look closely. Our roadmap to formal audit is below. Where this page says PCI-DSS Level 1, it describes our payment processor, Stripe; our own PCI self-assessment is on that roadmap too.
Scan report · On request
We use Aikido Security to scan our source code, our cloud accounts (AWS, Google Cloud and Azure) and our public web addresses for known weaknesses. You can ask for the security report Aikido produces from those scans — the badge opens Aikido's request form.
The report comes from an automated tool, so it is not an independent audit and not a certification.
Aikido's form asks for your name, your company and your email address, which reach Aikido and us so that we can answer your request — see section 2.7 of our Privacy Policy.
§ 03 · CONTROLS · 01–09
The whole schedule.
Nine control groups. The technical measures that run on the platform, grouped by what they protect. No marketing categories, no fluff — these are the controls shipped in the codebase and infrastructure, checked against the repositories on the review date above.
§ 01
Authentication & access
LIVE- Passkeys and two-factorWebAuthn passkeys on the buyer, trade and staff surfaces; authenticator-app two-factor with single-use backup codes for anyone who prefers it. Adding or removing a passkey needs a fresh step-up.
- Password policyAt least 12 characters, hashed with bcrypt, and any password found in a known breach is refused at the door.
- JWT access tokens15-minute expiry; short-lived by design. No long-lived bearer tokens in circulation.
- HttpOnly refresh cookiesRefresh tokens stored server-side in HttpOnly, SameSite cookies — never in localStorage, never reachable from JS.
- Token rotation + reuse detectionEvery refresh issues a new pair. Any attempted reuse of an old refresh token revokes the whole family and logs the event.
- Explicit session revocationSessions are per device by design. "Log out all devices", a password change or reset, a staff force-logout, and refresh-token reuse detection each revoke every session on the account. A session records a truncated IP address and keyed hashes of the IP and browser — not a browser fingerprint.
- Identity for high-value paymentsA buyer payment of £250 or more, or a critical-urgency request, needs a verified identity document and phone number on the account.
CONTROLS · 07 REF · AUTH-SVC
§ 02
Staff & admin controls
LIVE- A strong factor, or no accessA staff account needs a passkey or an authenticator app before it can do anything beyond its own setup. Separate credentials from customer accounts; separate tokens.
- Step-up before sensitive actionsA refund, a payout block, a role change or a data export asks the staff member to re-verify, and the proof lasts 5 minutes. Even the most senior account cannot skip it.
- Two-person approvalsAccepting a purchase order, voiding an invoice and retiring a category each need a second staff member. The person who asks cannot be the person who approves.
- Permissions, audited in CIEvery staff route carries a named permission from an audited catalogue, and the build fails on a staff route that has none.
- Hash-chained audit logEvery staff action against customer data — including every view of a proof of delivery or a document — is written to an append-only log where each row carries the hash of the one before. The database role cannot update or delete a row; the chain is verified nightly and anchored to object storage monthly.
- Lockout and alertingTen failed staff logins from one address in 15 minutes lock the account for 30 minutes. A new admin, a role change, a burst of failed logins or step-ups, or repeated bulk exports raise an alert to the on-call desk.
CONTROLS · 06 REF · STAFF-RBAC
§ 03
API & webhook security
LIVE- CSRF protectionOrigin-header validation on cookie-authenticated state-changing requests, so a cross-site forgery is rejected before it reaches business logic.
- Payment webhook signaturesEvery payment event is signature-verified against a shared secret before it can mutate an order or trigger a payout, and recorded in a durable ledger so a replayed event is recognised.
- Zod schema validationRequest bodies are parsed through typed Zod schemas. Unknown fields are stripped; malformed input is rejected at the edge.
- Idempotency and compare-and-setA money or staff request carries an idempotency key, so a retried call cannot act twice. Every state change claims its transition with a compare-and-set, so two racing requests cannot both win.
- Outbound fetches, SSRF-safeAn address the API fetches on a user's behalf — a supplier's stock file, a part link — passes a guard that refuses private and internal network ranges and never follows a redirect blind.
- Bot protection, fail-closedRegistration and the public forms are gated by Cloudflare Turnstile. If the check cannot run, the request is refused.
CONTROLS · 06 REF · API-GATEWAY
§ 04
Application security
LIVE- Hardened HTTP headersHSTS, X-Frame-Options, Referrer-Policy, and friends — applied via Helmet on every API response. Each client surface sets its own Content-Security-Policy; the buyer and trade apps allow only scripts whose hash the build emitted.
- Locked-down CORSCORS allow-list restricted to known GFP frontend origins. Wildcards do not exist in our config.
- DTO response boundaryInternal data models are never exposed directly — every response is filtered to a safe, typed shape.
- Typed error handlingErrors are mapped to typed, user-safe codes. No stack traces, SQL snippets, or internal paths leaked to clients, ever.
- Cloudflare-fronted ingressAll traffic passes Cloudflare's edge (DDoS mitigation, WAF); the origin rejects anything that didn't. The API trusts exactly the proxy hops in front of it, so a client cannot forge its own address.
CONTROLS · 05 REF · WEB-EDGE
§ 05
Rate limiting & abuse prevention
LIVE- Tiered request limits100 req / 15 min standard · 10 / 15 min for login · 3 / hr for registration. Graduated by surface area.
- Sensitive-operation limits5 / hr for sensitive account changes · 30 / 15 min for payment endpoints — stricter where the blast radius is larger.
- No door without a limitA route with no limit of its own gets a fallback of 1,200 requests per 15 minutes, and a contract test pins the few routes that opt out.
- Per-IP and per-user trackingDual-key counters make shared IPs and compromised accounts independently identifiable.
- Login throttling & staff lockoutThe login door is capped at 10 attempts per 15 minutes per IP. Staff accounts lock for 30 minutes after ten failures from one IP, and every attempt is recorded.
CONTROLS · 05 REF · RATE-LIMIT-SVC
§ 06
Money safety
LIVE- No card data on our serversCard details are captured and held by a PCI-DSS Level 1 processor — they never touch GoFindPart infrastructure.
- Kill switchesTen platform-wide switches — payments, payouts, releases, offers, requests, registrations among them — let the on-call desk halt one flow while the rest keeps running. A contract test checks every door that moves money against its switch.
- Reconciliation that never sleepsAn hourly sweep runs a pinned list of money-sum checks, and payout blocks and transfer recoveries are reconciled daily. A mismatch the sweep finds opens an issue on the staff reconciliation dashboard.
- Held until acceptedA buyer's payment is released to the seller only after the delivery is accepted, and a dispute freezes the payout the moment it is opened.
- Sanctions screeningSellers and credit applicants are screened against the UK Sanctions List at onboarding and nightly; a match blocks payouts and credit until a person clears it.
- Verifiable invoicesEvery GFP invoice carries a QR link and a code that confirm the issuer, the number, the total and the payee bank account — a check against invoice-redirection fraud.
CONTROLS · 06 REF · MONEY-DOORS
§ 07
Monitoring & incident response
LIVE- Structured logging (Pino)JSON logs with sensitive fields redacted at the logger layer — secrets, tokens, and PII never leave the request handler in plaintext.
- Sentry error trackingReal-time alerts on runtime errors, with release tracking and user-impact scoring routed to on-call. No session recordings, no form contents, no stored IP addresses.
- Prometheus metricsInfrastructure and business metrics exported for dashboards & alerting, with scheduled-job heartbeats monitored so a silent sweep is noticed.
- Incident response, written downDetection, containment, recovery and post-incident review follow a documented procedure, and affected customers are told by email within the regulatory timeframes.
- Emergency leversThe on-call desk can log every user out, force password resets, or lock a single account, platform-wide and at once.
CONTROLS · 05 REF · OBSERVABILITY
§ 08
Secure development & supply chain
LIVE- TypeScript strict modeEnforced across the entire codebase. A whole class of bugs never reaches runtime because the compiler rejects them.
- Static analysis on every changeCodeQL runs on all eight repositories on every pull request and weekly, alongside ESLint's security and quality rule sets at zero warnings tolerated.
- Secrets and licencesTruffleHog scans the API repository's full git history for verified live secrets on every push and blocks the build on a hit. A licence gate on the API and app repositories blocks any copyleft (AGPL, GPL, SSPL) dependency from entering the tree.
- Automated dependency scanningDependabot raises upgrade PRs on new advisories, and a blocking audit ratchet in CI fails the build on any new high or critical advisory in production dependencies. The container image is scanned on every build, and a new critical or high finding with a fix available blocks the merge.
- Commit and deploy gatesPre-commit hooks lint the staged files and typecheck the project. CI runs lint, typecheck, the test suite, and the build on every push and pull request, and the API deploys only after its contract pins and full test suite pass. Branch rules forbid force-pushes and deletions on every repository.
- Contracts, pinnedThe API's public contract, its error codes, its idempotency and kill-switch coverage and its rate-limit coverage are each pinned by a contract test that fails the build on drift. Third-party integrations are re-checked against the live services weekly.
- Infrastructure-as-codeDocker, deployment, and CI configuration are versioned in the repository and production is deployed from it. No hand-edited prod boxes.
CONTROLS · 07 REF · CI-PIPELINE
§ 09
Data, hosting & resilience
LIVE- UK-hosted primary storeAccount and marketplace data lives in the UK — database of record (Neon Postgres), file storage (AWS S3), and application servers all run in the London region.
- Controlled external flowsA small set of specialist sub-processors operate outside the UK (payments, error monitoring, document processing, email). Each transfer is covered by UK IDTAs, the UK Addendum to the EU SCCs, or a UK adequacy decision, and every one is named in our sub-processor register.
- Encrypted in transit & at restData is encrypted on the wire (TLS) and at rest in the UK store — see the full picture in our Privacy Policy.
- Backups that are proven to restoreThe database keeps 7 days of point-in-time recovery. Every week a full copy is taken off the database provider, restored into a scratch database and checked against the schema before it is kept in versioned object storage under our own keys.
- A weekly restore drillA separate weekly job restores production to a point in time and runs the money-invariant checks against the result, timed against a 30-minute recovery objective. A red run opens an issue the same day.
- Retention and erasure, scheduledRetention sweeps run nightly against written retention periods; a legal hold stops a sweep for one record and expires on a date; an account erasure cascades through the database and the file store.
CONTROLS · 06 REF · DATA-RESIDENCY
§ 04 · TRANSPARENCY · ROADMAP What's in place.
What's in place.
What's next.
Security is a schedule, not a sticker. This is what's shipped today versus what we're executing against for the remainder of 2026.
Current status
IN PLACE · TODAY- § 01 HTTPS everywhere · TLS 1.3End-to-end encryption for every request — no HTTP fallback, HSTS with the preload directive.
- § 02 Automated vulnerability scanningDependency audits gate every CI run. The container image is scanned on every build, and a new critical or high finding with a fix available blocks the merge. Aikido Security also scans our code, our cloud accounts and our public web addresses (scan report); it does not scan the configuration of the platforms that host the API and its database.
- § 03 Responsible disclosure, publishedA security.txt at the standard address names the security desk and this policy, and a safe-harbour statement for good-faith research is below.
- § 04 Privacy-by-design architectureData minimisation, PII redaction, and subject-access built into the platform from day one — not retrofitted.
Planned initiatives
ROADMAP · 2026- → 01 SOC 2 certificationWe plan to engage an auditor for a Type I report in Q4 2026, with Type II to follow in 2027. No audit engagement has started yet; mapping our controls to the framework is the current work.
- → 02 Third-party security audit programmeWe intend to commission independent penetration tests and code & architecture reviews on a recurring cadence and to share summarised reports with enterprise customers. None has been completed yet.
- → 03 Bug bounty programmeWe intend to launch a public bounty for responsible-disclosure researchers — scoped, scored, and paid out through an established platform. Until then, good-faith reports go to the security desk below.
- → 04 PCI DSS self-assessmentCard data never touches our systems, which puts us in the lightest self-assessment class. Our first SAQ A filing and the quarterly external scans that go with it are planned for Q4 2026; they have not been filed yet.
- → 05 ISO 27001 certification pathwayGap analysis, ISMS scoping and policy work are planned, not started. Our compliance calendar targets certification in 2028, after SOC 2.
§ 05 · RESPONSIBLE DISCLOSURE Found something?
Found something?
Tell us first.
If you've discovered a security vulnerability in GoFindPart — or even just something that looks off — we'd rather hear about it directly than read about it. Good-faith disclosure is protected, encouraged, and credited.
- 01 We acknowledge receipt of every report within 48 hours.
- 02 Initial assessment & triage delivered within 5 business days.
- 03 We will not take legal action for good-faith security research, provided it respects our scope & rules of engagement.
- 04 Credit given in our published advisory — or kept confidential, at your preference.
§ 06 · STILL HAVE QUESTIONS
The desk is open.
Procurement, infosec review, vendor questionnaire, security-documentation request — we respond to all of it. No sales filter, no "schedule a call" wall.
Attestation
This document is the security page at gofindpart.com/security/ as published on the review date above. Every claim in it has a row in GoFindPart's claims register naming its evidence, and the site's build fails when a claim and its row disagree.
Questions, vendor questionnaires and security-documentation requests: security@gofindpart.com. A vulnerability report to the same address is acknowledged within 48 hours.
Claims reviewed2 October 2026Rev. 26.10
GoFindPart · Security · Status report · Rev. 26.10 Claims reviewed 2 October 2026 · Printed from gofindpart.com/security/ · The live page prevails