Plain answers about how we build, test and release ProductHub — and how we separate product data, your systems, and marketing leads.
Security at ProductHub is layered: written engineering standards, automated checks in our pipeline, controlled release paths, and human review when we need exceptions. We describe what we do today in practical terms — not fear marketing and not certifications we do not hold.
ProductHub maintains approved Engineering Standards, currently version 1.6 (November 2026). Each product repository pins an approved revision and runs automated standards checks before releases. Documented exceptions are used when policy cannot be met yet, with an audit trail.
On our main development branch, continuous integration runs linting, type-checking, tests, standards verification, and production builds for web, API, hub and mobile components. Checks use the lockfile and do not deploy or touch live customer databases.
Code reaches staging only from tested commits, is deployed and accepted there, then the same commit may be promoted to production. Component deploys are manual and recorded. Release workflows support rollback when a deploy needs to be reversed.
When a component cannot yet meet a standard, we record a named exception and track it until resolved. This keeps gaps visible rather than silent.
We are extending our assurance programme with authorised proactive security review, working with external specialists and our own team where appropriate. This sits alongside — not instead of — standards, CI and release discipline.
Membership and platform services hold the product records you maintain with ProductHub. Access is account-based. Operational boundaries (such as authenticated API access) are tested in our codebase. Specific hosting, retention and subprocessors belong in your agreement and our Privacy Policy — not on this marketing page.
ProductHub may integrate with your ERP, PIM, storefront or spreadsheets. You control credentials, network access and what you export. We design for clear data flows, but your internal controls remain your responsibility.
The public site collects enquiries through our contact form. In production, submissions are protected by Cloudflare Turnstile verified on the server, a hidden honeypot field, and field validation before any CRM handoff. Staging may run without live CRM integration. Lead handling is described in our Privacy Policy and Terms of Use.
For vendor questionnaires, security packs or mutual NDAs, contact us with your scope and timeline. We share what we can from documented policies and architecture; bespoke legal terms require sign-off from ProductHub leadership.
Request security informationWe combine written engineering standards, automated CI checks, staged releases with acceptance, and recorded exceptions when something cannot meet policy yet. Client product data in our services is accessed through account controls; your own systems keep their own security posture.
We separate product platform data, data in your integrated systems, and marketing leads from this website. For legal detail, see our Privacy Policyand Terms of Use.
Yes. ProductHub maintains approved Engineering Standards, currently version 1.6 (November 2026). Our repositories pin an approved revision and run automated standards checks as part of verification. We do not quote internal repository paths or commit identifiers on this public page.
Changes on our development branch run through automated linting, type-checking, unit and integration tests, standards checks, and builds for affected components (marketing site, members, API, mobile and supporting packages) before promotion.
Passing CI on a commit is required before that commit can move toward staging release.
We promote an exact tested commit to staging, deploy components there, record acceptance, then promote the same commit to production. Deployments are component-specific and manual.
Release workflows include rollback actions so a problematic deploy can be reversed without improvising on live servers.
Yes for the marketing contact form served from this codebase. The browser completes Cloudflare Turnstile; the server verifies the token with Cloudflare before accepting a submission. We also use a honeypot field and strict validation on names, email and message length.
If verification fails, the message is not processed.
Contact form data is used to respond to your enquiry and, in production, may be passed to our CRM when configured. Staging environments may accept messages without live CRM connectivity.
See our Privacy Policy for collection, use and retention. This page does not replace that policy.
Access to platform features is account-based. Our API enforces authentication for protected routes, which we test in the codebase. Transport uses HTTPS in production environments.
We do not claim “unhackable” or “100% secure” systems. Hosting details, subprocessors and contractual commitments are covered in customer agreements and privacy documentation.
Yes. Use our contact form with subject “Support” or your usual account channel and describe your questionnaire, NDA or audit scope. We will confirm what we can provide and any items that need leadership sign-off.
We prioritise containing impact, restoring service, and understanding root cause. Technical rollback options exist for deployed components when a bad release is involved.
Customer communication and regulatory obligations depend on contract and jurisdiction — contact us if you believe there is an active issue affecting your data.
ProductHub does not currently advertise ISO, SOC 2, PCI or other formal certifications on this site. Our public position is the practices described here: standards, CI, staged release, exceptions, and our extending proactive assurance programme — not third-party badges we have not earned.
Tell us what you need — a questionnaire, architecture overview, or incident report.
Contact ProductHub