Product configurator security and privacy guide
A secure product configurator gives each visitor, customer, dealer, employee and connected system only the data and actions required for the accepted workflow. This guide turns that principle into a data map, access model, API contract and permanent acceptance test pack.
Six data classes
Know what the workflow handles
Seven access roles
Separate audience and authority
Twelve acceptance tests
Replace claims with evidence
Eighteen buyer FAQs
Answer security questions clearly
Clear definition
A product configurator sits between public product discovery and private commercial operations. It can expose a catalogue on a website, accept customer measurements and photos, calculate prices, store dealer projects, generate quotes and deliver approved data to CRM, ERP, ecommerce, document and production systems. Each transition changes the audience, sensitivity and consequence of an action.
The security model therefore starts with five questions: what resource is being requested; who or what is requesting it; which action is attempted; under which account, market and environment; and what evidence records the result. Authentication identifies an actor. Authorization still has to decide whether that actor may use this exact project, quote, price list, file, rule, function or integration.
A strong requirement names the control, owner, enforcement point, evidence, test, review cadence and exception process. “Enterprise security” is not a test. “A dealer cannot read, count, export or receive events for another dealer’s projects” is a testable boundary.
Interactive security scope
Select a surface to see how purpose, identity, data, permitted actions, denied data, lifecycle and evidence change. Use this as a starting model; the accepted deployment should name every real audience and system.
Website visitor or invited customer
Explore valid products, save a project and request a quote without exposing private catalogue or account data.
Anonymous session, signed project link or customer identity—selected by the journey and risk model.
Data required
Permitted actions
Boundary conditions
Acceptance evidence
Anonymous-access test, project-link expiry test, response-field inspection and cross-project authorization test.
Lifecycle
Define session, draft-project and shared-link lifetime separately.
Outbound boundary
Lead or project event to the accepted CRM, quote or workflow endpoint.
Control architecture
These domains are connected. Identity without object authorization still leaks projects. Encryption without key ownership leaves an unanswered boundary. Backups without a restore and access test do not prove recovery.
What enters the system, why, and how sensitive is it?
Map customer contact details, addresses, site photos, product selections, prices, discounts, drawings, documents, model assets, analytics identifiers and integration payloads. Classify each field before choosing storage, access, retention and export rules.
Evidence
Field-level data map with purpose, owner, sensitivity, location, recipients and retention.
Who or what is making the request?
Separate anonymous visitors, invited customers, dealer users, workforce users, administrators and machine identities. Define sign-in, federation, stronger authentication, recovery, invitation, service credentials and deprovisioning according to risk.
Evidence
Identity journeys, authentication policy, recovery test and joiner-mover-leaver test.
May this identity perform this action on this exact object?
Check role, account, project, object, action, market and environment on the server. A user who may view one quote must not automatically view another; an administrator action must not be inferred from a hidden button.
Evidence
Positive and negative object-level tests across roles, accounts, records and endpoints.
Which product knowledge reaches the customer device?
A web configurator necessarily sends visual and interaction data to a browser. Decide whether geometry, textures, option IDs, pricing inputs, rule metadata or document links are public, transformed, signed, time-limited or kept server-side.
Evidence
Network-response inspection and asset-access test performed as an unauthenticated visitor.
Can integrations exchange data without widening access?
Protect every object and function, validate payloads, limit resource use, verify webhook origin, reject replay where required, keep an API inventory, control versions and treat third-party responses as untrusted input.
Evidence
Contract tests for identity, object access, schema, signature, replay, rate, timeout and retry behavior.
Where do credentials live and who can use them?
Keep service credentials, signing keys and administrative secrets out of browser bundles, repositories and documents. Separate development, test and production responsibilities, rotate credentials and verify revocation.
Evidence
Secret inventory, access list, rotation record, client-bundle scan and revoked-secret test.
Can the organization reconstruct security and business-critical events?
Capture who or what acted, the target, action, result, time, tenant, correlation identifier and relevant revision. Keep security events distinct from business analytics and avoid placing credentials or unnecessary personal data in logs.
Evidence
Event catalogue, sample records, access controls, retention, alert path and investigation exercise.
How is personal data minimized, retained, corrected, exported and deleted?
Connect each personal-data field to a purpose and lifecycle. Define controller and processor responsibilities, subprocessors, data-subject handling, regional transfer needs, backups and the effect of deletion on quotes, orders and legal records.
Evidence
Processing record, DPA responsibilities, retention schedule and completed access/deletion scenario.
What happens when a dependency or region is unavailable?
Define recovery objectives from the business process, not from a generic uptime slogan. Test backup restoration, degraded journeys, queued integrations, idempotent retry and reconciliation after service returns.
Evidence
Recovery objectives, restore result, dependency-failure test and reconciled record sample.
How are risks prevented and corrected after launch?
Security is a release process. Define dependency and code scanning, review gates, vulnerability intake, severity, remediation targets, emergency change, environment promotion and retesting of affected access and data flows.
Evidence
Change record, scan result, remediation workflow and regression evidence linked to a release.
Who decides, contains, communicates and learns?
Name the operational contacts and evidence sources before an incident. Cover account compromise, cross-tenant exposure, malicious files, credential leakage, abusive automation, integration compromise and incorrect public publishing.
Evidence
Incident roles, contact path, severity model, tabletop result and corrective-action record.
Which external service receives or protects the data?
Inventory hosting, authentication, email, storage, analytics, support and integration providers. Record their role, data, region, contract, access, dependency, change-notification route and exit plan.
Evidence
Current supplier register, subprocessor list, responsibility boundary and offboarding test.
Data classification
Product names and public textures do not need the same controls as margins, customer addresses, BOMs or service credentials. Classification makes access, storage, retention and integration decisions explainable.
01
Public names, finishes, options, thumbnails and allowed product descriptions.
May be intentionally public, but draft and withdrawn revisions still need publishing controls.
02
Costs, margins, dealer price lists, discount ceilings, account terms and internal price formulas.
Restrict by role and account; return only the commercial result needed by the current journey.
03
Name, contact details, address, site dimensions, photos, notes and appointment information.
Minimize collection, state purpose, control access and connect retention to the business record.
04
Saved configuration, revisions, price results, documents, approvals, deposits and status history.
Protect object-level access and preserve enough revision context to explain the accepted transaction.
05
BOM, cut values, drawings, surveys, installation files, ERP identifiers and delivery status.
Limit to accepted operational roles and verify the exact revision delivered downstream.
06
Credentials, tokens, logs, environment details, errors, dependency versions and security findings.
Separate secrets from observable records; restrict logs and findings while keeping them useful for response.
Authorization matrix
A real policy also considers the target account, object, action, market, sharing state, environment and approval context. This compact matrix makes the first separation visible before object-level tests are written.
| Identity | Catalogue | Projects | Pricing | Discount | Publish |
|---|---|---|---|---|---|
| Website visitor | Published catalogue | Own draft or signed link | Public result | No | No |
| Customer | Published catalogue | Own invited projects | Own permitted quote | No | No |
| Dealer salesperson | Account catalogue | Account projects | Account price context | Limited | No |
| Sales manager | Assigned markets | Team projects | Approved price context | Approve | No |
| Product manager | Draft + published | Review samples | Rule test context | No | Prepare |
| Platform administrator | As authorized | As authorized | As authorized | No | Publish/rollback |
| Integration service | Contracted fields | Event object only | Contracted result | No | No |
Configurator-specific threat model
Generic security lists are useful, but a configurator has distinctive assets and business flows: customer project links, account catalogues, live prices, models, quotes, publishing actions and operational webhooks.
A signed-in user changes a project or quote ID and receives another customer or dealer record.
Enforce object-level authorization for every read, update, export and document request; test IDs from another account.
The public client receives internal costs, margins, unpublished rules or dealer-only price lists that the interface merely hides.
Design response schemas for the current audience and inspect actual browser traffic, not only visible screens.
A dealer user searches, exports or opens projects belonging to another dealer, branch or brand.
Apply account scope server-side to queries, files, exports, analytics and integrations; include negative tenant tests.
Automated requests consume rendering, document, email, storage or pricing resources and interrupt legitimate buyers.
Set business-aware rate, concurrency, payload and cost limits; monitor unusual patterns and protect sensitive flows.
An untrusted request marks a quote accepted, creates an order or repeats an earlier event.
Authenticate origin, validate signatures and timestamps, enforce idempotency and reconcile the resulting state.
A forwarded quote or project link remains valid beyond its purpose or exposes editing and private fields.
Scope the link to an object and action, define expiry and revocation, and test anonymous access after status changes.
Site photos, drawings or attachments are used to deliver malicious files, unexpected content or excessive storage load.
Validate type and size, isolate storage and delivery, control access, scan where required and never trust the filename alone.
Draft prices, products, assets or rules are published to the wrong market, brand or dealer network.
Separate preparation from approval where risk warrants it; preview scope, log the change and support controlled rollback.
Privacy lifecycle
A lead can be copied into email, CRM, quote PDFs, file storage, analytics, exports and backups. Privacy design maps the complete lifecycle and the responsibility at every destination.
Ask only for information required by the journey. Separate optional marketing choices from project data.
Connect every field to a stated purpose, authorized role and approved system destination.
Identify processors, subprocessors, recipients, regions, transfer needs and customer-facing documents.
Set lifecycles for leads, drafts, quotes, orders, uploads, logs and backups rather than one universal period.
Define access, correction, export, restriction and deletion handling across primary and downstream records.
Delete or anonymize according to policy, preserve required transaction history and document backup expiry.
Audit event contract
Infrastructure access logs cannot explain every product or commercial action. The application knows the actor, tenant, object, revision, policy and business outcome. Capture that context without copying credentials or unnecessary sensitive content.
{
"eventId": "evt_01J7SEC92",
"occurredAt": "2026-08-19T14:42:11Z",
"environment": "production",
"tenantId": "tenant_havenform",
"actor": {
"type": "user",
"id": "usr_84P2",
"role": "sales_manager"
},
"action": "quote.discount.approved",
"target": {
"type": "quote",
"id": "quo_2418",
"revision": 4
},
"result": "allowed",
"policy": "discount-approval-v7",
"correlationId": "req_C8J41"
}Security acceptance test pack
Use representative accounts, projects, files and integrations. Record environment, release, preconditions, expected result, actual evidence, owner and any exception.
Use a valid user and request a project, quote, document and export owned by another permitted test account. Every route must deny access without leaking record content.
Evidence required
Search, filter, count and export from one dealer account using identifiers known to exist in another account. Results and totals must remain isolated.
Evidence required
Remove discount, export or publishing permission from an active user. The next protected action must follow the new policy, including direct API requests.
Evidence required
Disable a workforce or partner identity. Test active sessions, refresh, invitations, API access and ownership transfer according to the accepted policy.
Evidence required
Inspect page source, network payloads, 3D assets, files and error responses as an anonymous visitor. Confirm private product and price fields are absent.
Evidence required
Open a valid shared project, then test expiration, revocation, quote acceptance, project revision and forwarding to a different browser.
Evidence required
Send an unsigned, wrongly signed, expired, replayed, reordered and duplicated event. Verify rejection or idempotent handling and attributable logs.
Evidence required
Exercise accepted maximum dimensions, option counts, file sizes, quote requests, exports and concurrent calculations. Verify stable errors and protected service availability.
Evidence required
Perform sign-in, denied access, price approval, export and publishing actions. Reconstruct who, what, when, object, tenant, result and correlation without exposing secrets.
Evidence required
Expire a test lead and complete the approved deletion or anonymization flow across the primary record, searchable views, files, integrations and documented backup behavior.
Evidence required
Restore a representative catalogue, configuration and project set. Verify object identity, access policy, files, revisions and downstream reconciliation—not only database startup.
Evidence required
Interrupt one agreed external service. Confirm the intended degraded journey, queued or failed state, alerts, safe retry and reconciliation after recovery.
Evidence required
Enterprise due diligence
Ask the same questions of every supplier. Require a named answer, owner and evidence for the actual deployment—not a generic feature checklist.
Which data fields enter the configurator, from which source, for which purpose and in which region?
Which party is controller or processor for each customer, dealer, workforce and analytics journey?
How are public, customer, dealer, workforce, administrator and machine identities separated?
Where is authorization enforced for projects, quotes, files, price lists, exports and administrative functions?
How is tenant or account scope applied to searches, counts, analytics, documents and downstream events?
Which product, price, rule, model and document data reaches the browser or a public asset URL?
How are API objects, functions, fields, payload sizes, rates, versions and external responses controlled?
How are webhooks authenticated, replay-protected, retried and reconciled?
Where are credentials stored, how are environments separated, and how are secrets rotated and revoked?
Which authentication, federation, stronger-authentication and recovery options apply to each role?
Which security and privileged business events are logged, protected, monitored and retained?
Which personal-data fields are optional, required, exported, corrected, anonymized or deleted?
Which subprocessors receive data, in which regions, under which responsibility and change process?
What are the accepted backup, recovery, availability and dependency-failure objectives?
How are vulnerabilities reported, prioritized, corrected, communicated and retested?
Which security checks run before a catalogue, rule, pricing, integration or platform release?
How are customer uploads validated, scanned, stored, served and removed?
How are security incidents classified, investigated, communicated and connected to corrective action?
What evidence is supplied at acceptance and on an agreed recurring cadence?
Who owns every open exception, compensating control, deadline and risk acceptance?
Primary references
These sources provide current primary guidance. They do not make a deployment secure by citation; they help teams write consistent controls and verification criteria.
A testable requirements framework for application technical security controls and procurement language.
Primary risk reference for object and function authorization, authentication, resource consumption, inventory and third-party API consumption.
An architecture reference centered on protecting resources and making explicit authentication and authorization decisions.
Current NIST guidance for identity proofing, authentication, federation and related lifecycle processes.
Primary legal text covering controller and processor responsibilities, data protection by design and security of processing.
Application-focused guidance for event selection, attributes, protection, monitoring, retention and disposal.
Security and privacy FAQ
Continue the evaluation
Define OpenID Connect or SAML federation, SCIM provisioning, role mapping, dealer tenancy, sessions and service identities.
Open guideProtect the identity, lifecycle, synchronization and authority boundaries between configured products, installed assets and operational state.
Open guideDefine source ownership, API and webhook contracts, delivery state, retries and reconciliation.
Open guideApply tenant, object, property, function and resource controls across public and private configuration contracts.
Open guideGive product, configuration, customer and operational records stable identities and explicit ownership.
Open guideTurn security, privacy and operational expectations into owners, phases, evidence and acceptance.
Open guideWrite testable procurement requirements across data, access, integrations, outputs and maintenance.
Open guideControl access, publishing, changes, environments, saved projects and regression evidence after launch.
Open guideProtect component identity, configured orders, production structures and operational handoff.
Open guideDecide what reaches the browser, version asset dependencies and validate runtime delivery without exposing private product data.
Open guideCombine security evidence with rules, pricing, accessibility, integration, recovery and release acceptance.
Open guideMake security part of product discovery