When would I use this?

Start here if you are deploying TrustPlane for the first time or taking ownership of an existing environment.

What to do

1. Identify the exact TrustPlane release and the deployment profile supplied for your environment.
2. Assign customer owners for infrastructure, database, identity, PKI/keys, privacy operations and application integration.
3. Complete the deployment readiness checklist before installing production software.
4. Follow the guide in sequence for a new deployment; use Search for an existing environment.

How you know it worked

• The deployment profile and environment are recorded.
• Named customer owners exist for each required dependency.
• Release-specific support, compatibility and sizing information is available.

When would I use this?

Use this as the master sequence for a new deployment.

What you need before you start

• Confirmed commercial scope and enabled capabilities
• Named deployment owner

What to do

1. Plan — choose the availability, recovery and connectivity model.
2. Prepare — provision network, DNS/time, certificates, PostgreSQL, storage, identity and key services.
3. Install — verify the release package and deploy the selected topology.
4. Commission — establish customer trust, administrators, entitlements and regulatory content.
5. Connect — onboard applications, identity/data sources and consent channels.
6. Validate — prove security, workflows, backup/restore and resilience in the actual environment.
7. Operate — monitor, patch, back up, rotate trust material and troubleshoot without weakening controls.

How you know it worked

• Each phase has an accountable owner and acceptance evidence.
• Production go-live occurs only after validation is complete.

When would I use this?

Use during project kickoff and operational handover.

What to do

1. Nominate a Deployment Lead to coordinate environment readiness and acceptance.
2. Nominate Infrastructure/Platform owners for compute, operating system or container platform, load balancers and network.
3. Nominate Database and Storage owners for PostgreSQL, backup, WAL/PITR and evidence/object storage.
4. Nominate Identity and Security owners for SSO, directory integration, PKI, KMS/HSM, secrets and firewall controls.
5. Nominate Privacy/Compliance administrators for organisation setup, regulatory content, notices, rights, assessments and reporting.
6. Nominate Application owners for APIs, SDKs, web/mobile channels and downstream enforcement.
7. Keep approval duties separate where maker-checker or segregation-of-duties controls apply.

How you know it worked

• Every dependency and governed approval has a named customer owner.
• No shared emergency account is being used as normal administration.

When would I use this?

Complete before provisioning production infrastructure.

What you need before you start

• Business availability requirements
• Recovery objectives
• Data-location and connectivity constraints

What to do

1. Choose a standard single-site deployment when high availability is not part of the acceptance scope.
2. Choose a high-availability profile when application and database redundancy are required.
3. Choose a multi-site or disaster-recovery profile when site loss must be addressed.
4. Choose a disconnected/air-gapped operating pattern where Internet access is not permitted.
5. Document failure domains, recovery expectations, key/evidence dependencies and approved external integrations.
6. Confirm the exact topology against the release-specific deployment profile.

How you know it worked

• Topology, failure domains and recovery model are documented.
• The selected profile is supported by the exact release.

The short version

Minimum deployment prerequisites

Minimum TrustPlane software architecture you should expect

How you know it is ready

• The exact TrustPlane release and deployment profile are known.
• The release BOM/support matrix is available and matches the planned environment.
• PostgreSQL, storage, backup, DNS, time, TLS and administrator identity are ready.
• Only the required firewall paths have been approved.
• There is a named owner for infrastructure, database, identity/security and privacy administration.
• No production value has been guessed from a demonstration or QA environment.

When would I use this?

Use during architecture review and security sign-off.

What to do

1. Treat PostgreSQL as the authoritative TrustPlane transactional database.
2. Keep browsers, caches, SDK local state and external systems from becoming parallel sources of truth.
3. Keep core runtime, evidence and regulatory content inside customer-controlled infrastructure.
4. Use external services only through explicitly approved connectors or integrations.
5. Ensure loss of an optional telemetry or external integration does not silently change authoritative privacy state.
6. Preserve offline/manual paths where the selected profile requires disconnected operation.

How you know it worked

• No browser or external SaaS service is configured as an authority store.
• Core protected workflows can operate without a mandatory TrustPlane cloud dependency.

When would I use this?

Run before change windows, production build or implementation handoff.

What to do

1. Exact signed release package and verification metadata are available.
2. Release support matrix and sizing/BOM are available.
3. DNS names, IP/VIP plan and trusted time sources are approved.
4. TLS/PKI ownership and certificate issuance path are approved.
5. PostgreSQL topology, backup and recovery owners are assigned.
6. Evidence/object storage and key-management design are approved where used.
7. SSO/IdP integration and administrative role mapping are approved.
8. Firewall flows are approved using actual source and destination zones.
9. Regulatory/country content and commercial entitlements are identified.
10. A non-production validation environment exists where required by your change policy.

How you know it worked

• No mandatory item is marked unknown before production install starts.

When would I use this?

Use for procurement, VM/container sizing and upgrade planning.

What you need before you start

• Exact release identifier

What to do

1. Read the release support matrix and compatibility manifest.
2. Use measured capacity guidance for your expected user, application, event and evidence volumes.
3. Confirm supported operating-system/container platform versions and browser versions.
4. Confirm the database, HA, backup, storage and key-management profile supported by the release.
5. Record the final platform matrix as part of deployment evidence.

How you know it worked

• The deployed platform matches a supported release profile.
• No production sizing was copied from QA or demonstration infrastructure.

When would I use this?

Use when designing VLANs, security groups, firewalls or container NetworkPolicies.

What you need before you start

• Approved network architecture

What to do

1. Create logical trust zones for user access, TrustPlane services, databases/storage, security services and integrations.
2. Start with default-deny ingress and egress where the platform permits.
3. Allow browser users to reach customer ingress only; do not provide direct database, storage or key-service access.
4. Restrict application-to-database, application-to-storage and application-to-key-service flows to the required service identities.
5. Allow connector egress only to approved destinations and ports.
6. Revalidate rules after DNS, load-balancer, site or connector changes.

How you know it worked

• No user zone has direct database/object-store/KMS access.
• Unlisted egress is denied or otherwise controlled by the customer network policy.

When would I use this?

Use during firewall review and connectivity troubleshooting.

What you need before you start

• Source/destination FQDNs or VIPs
• Release-specific listener configuration

What to do

1. Resolve the exact source zone, destination FQDN/VIP and listener for every required flow.
2. Use the common ports below only as planning defaults; confirm each value against your environment.
3. Implement narrowly scoped rules and record the firewall rule/change identifiers.
4. Test connectivity from the actual source host, pod or network segment.
5. Validate TLS and application behavior, not only a successful TCP connection.

How you know it worked

• Every allowed flow has a documented business/technical purpose.
• Actual configured ports match approved rules.

Reference details

When would I use this?

Configure before commissioning and revalidate after network/site changes.

What you need before you start

• Approved DNS resolvers
• Approved NTP/time sources

What to do

1. Resolve TrustPlane ingress, IdP, database endpoints, storage, key services and configured connectors from their real source zones.
2. Configure approved time sources on all participating nodes.
3. Compare UTC time across application, database, ingress and security nodes.
4. Monitor resolution failures and clock skew.
5. Treat material clock uncertainty as an operational issue before performing time-sensitive governed actions.

How you know it worked

• All required names resolve from the intended source zones.
• Node time is synchronized within the customer-approved tolerance.

When would I use this?

Use during initial deployment, certificate rotation and integration setup.

What you need before you start

• Certificate authority/trust model
• Approved DNS names/SANs

What to do

1. Inventory every certificate purpose, subject/SAN, issuer, expiry and consumer.
2. Issue customer-approved certificates for ingress and any workload identities required by your profile.
3. Install only the necessary trust roots/intermediates.
4. Keep certificate-chain and hostname verification enabled.
5. Use the release-approved TLS profile; do not enable obsolete protocol versions for compatibility shortcuts.
6. Test expiry/rotation before production and schedule certificate ownership.

How you know it worked

• Browser/API TLS validates without bypasses.
• All internal/external peers use the intended trust chain.

When would I use this?

Use for every production deployment.

What you need before you start

• Supported PostgreSQL profile from the release package
• Backup/recovery design

What to do

1. Provision the PostgreSQL topology required by the selected deployment profile.
2. Create separate least-privilege roles for runtime, migration, reporting and backup functions where defined by the release.
3. Restrict network access to TrustPlane services and approved recovery/admin paths.
4. Enable database TLS according to the selected profile.
5. For HA, ensure application writes target the current authoritative leader endpoint only.
6. Configure backup and WAL/PITR where required before onboarding production data.

How you know it worked

• TrustPlane cannot accidentally write to a stale or read-only database member.
• Backup/archive health is observable.

When would I use this?

Use during infrastructure build, HA/DR design and recovery testing.

What you need before you start

• Supported storage profile
• Retention and backup requirements

What to do

1. Provision the storage endpoint or local/object-storage profile supported by your release.
2. Use a least-privilege service identity or secret reference.
3. Restrict network access to the required TrustPlane services.
4. Perform a write/read integrity test and record the result.
5. Include evidence storage in backup, recovery and site-failover testing.
6. Enable immutability/WORM only when the chosen storage platform is actually configured and validated for it.

How you know it worked

• A test object can be written, read and integrity-checked.
• Recovery procedures include evidence objects, not only database rows.

When would I use this?

Use where customer-managed keys or HSM/KMS integration is part of the selected profile.

What you need before you start

• Supported provider/adapter
• Customer key lifecycle policy

What to do

1. Provision purpose-separated key handles and access policy.
2. Configure the release-supported provider endpoint, socket or library.
3. Store references/credentials through the approved secret-management path.
4. Open only the provider-required network path where the key service is networked.
5. Run the release-supported capability/self-test.
6. Test provider outage and recovery; required signing/unwrapping operations must not silently fall back to weaker key handling.

How you know it worked

• Application configuration contains references, not private keys.
• Required key operations fail safely when the provider is unavailable.

When would I use this?

Configure before routine administrator access is enabled.

What you need before you start

• IdP metadata/endpoints
• Approved group/claim-to-role design
• MFA/step-up policy

What to do

1. Configure the supported OIDC or SAML identity-provider profile.
2. Validate issuer/entity ID, audience, redirect URLs and signing trust.
3. Map customer groups/claims to TrustPlane roles using least privilege.
4. Test successful login, denied access, role changes, disabled users and session revocation.
5. Test MFA/step-up where required for privileged actions.
6. Remove or rotate bootstrap access after customer SSO is proven.

How you know it worked

• At least two distinct authorized administrators can sign in using customer identity.
• A user without the required group/claim is denied.

When would I use this?

Use when TrustPlane needs enterprise subject aliases or directory-backed identity data.

What you need before you start

• Approved directory source
• Least-privilege directory credential
• Attribute minimisation

What to do

1. Configure the supported directory connector profile.
2. Use LDAPS/HTTPS or the secure mechanism approved for the connector.
3. Map only the attributes required for the defined use case.
4. Run a connectivity test and a bounded synchronization.
5. Review ambiguous, recycled or renamed identifiers before high-impact use.
6. Monitor connector failures separately from administrator SSO.

How you know it worked

• Directory sync is least-privilege and attribute-minimized.
• Directory records do not directly overwrite consent or governed subject truth.

When would I use this?

Use where email or other messaging is enabled for governed workflows.

What you need before you start

• Approved relay/provider
• TLS/authentication policy

What to do

1. Configure the exact relay/provider endpoint and credentials using secret references.
2. Restrict egress to the approved destination.
3. Send an approved test notification.
4. Record provider/message identifiers and retry/failure behavior.
5. Test an outage to confirm the authoritative workflow remains intact.

How you know it worked

• Notifications can be sent and failures are visible.
• No workflow is falsely closed because a transport provider accepted a message.

When would I use this?

Use for every online or offline release bundle.

What you need before you start

• Release package
• Published digest/signature/manifest from the delivery channel

What to do

1. Record the bundle filename, size, source and declared version.
2. Verify the provided cryptographic digest/signature using the release-supplied method.
3. Review compatibility, predecessor and deployment-profile requirements.
4. Review supplied component/SBOM information where included.
5. Quarantine any mismatch; do not install a package whose identity cannot be verified.
6. Retain verification output with the deployment change record.

How you know it worked

• Package verification succeeds against the expected release metadata.
• The installed package is the same artifact that was approved.

When would I use this?

Use for the supported non-HA production profile.

What you need before you start

• Completed infrastructure prerequisites
• Verified release bundle
• Approved change window

What to do

1. Provision hosts or platform resources from the exact release BOM.
2. Configure ingress/TLS, PostgreSQL, evidence storage, key services and backup as required by the profile.
3. Apply approved firewall rules.
4. Install TrustPlane using the release-supplied installer or deployment automation.
5. Run database migrations and service bootstrap using the documented release procedure.
6. Complete first-boot commissioning and post-install validation.
7. Run an initial backup and a recovery verification appropriate to the profile.

How you know it worked

• All required services report ready.
• Customer SSO works.
• A representative governed workflow and evidence write succeed.
• Backup/recovery evidence exists.

When would I use this?

Use when HA is part of the contracted and accepted deployment scope.

What you need before you start

• HA profile from the exact release
• Defined failure domains
• Load balancer/ingress
• Database HA/quorum/fencing design

What to do

1. Provision application and database members across the required failure domains.
2. Deploy the supported PostgreSQL HA mechanism and distributed coordination/quorum components where required.
3. Configure fencing so a stale or isolated database member cannot remain a writer.
4. Deploy redundant TrustPlane application/UI/worker instances as defined by the release profile.
5. Configure leader-only database write routing and redundant storage/key/backup dependencies.
6. Perform controlled failover and failback tests.
7. Capture evidence that the former primary cannot continue writing after loss of authority.

How you know it worked

• Only one database write authority exists at a time.
• Application traffic shifts without bypassing readiness.
• Failover/failback results meet the agreed acceptance profile.

When would I use this?

Use in sovereign, restricted or disconnected environments.

What you need before you start

• Approved transfer process
• Local runtime dependencies
• Offline release and regulatory-content bundles

What to do

1. Prepare the customer-controlled transfer repository or media process.
2. Verify package digests before and after transfer.
3. Provision all required runtime services locally.
4. Install and commission TrustPlane with unapproved egress blocked.
5. Import signed regulatory/control content through the governed local workflow.
6. Test representative privacy operations with Internet access physically or logically unavailable.
7. Document the offline update and support procedure.

How you know it worked

• Core protected workflows remain usable without Internet access.
• Offline bundles retain verifiable provenance after transfer.

When would I use this?

Run immediately after installation or major recovery.

What you need before you start

• Required infrastructure dependencies reachable

What to do

1. Check liveness and readiness separately; investigate any explicit dependency failure.
2. Rotate or remove bootstrap credentials according to the release procedure.
3. Establish customer trust material and key-provider connectivity.
4. Configure customer SSO and create at least two distinct privileged users where segregation is required.
5. Set the organisation/deployment identity.
6. Import entitlements and approved regulatory content.
7. Run the post-install validation suite.

How you know it worked

• No bootstrap credential remains as an undocumented standing account.
• Required dependencies are ready.
• Customer identity and administrative authorization work.

When would I use this?

Use during first commissioning, renewal, rehost or entitlement change.

What you need before you start

• Signed entitlement material
• Deployment identity

What to do

1. Import entitlement material using the TrustPlane administration workflow.
2. Verify that the entitlement is bound to the expected deployment identity and product scope.
3. Review enabled capabilities, deployment options and jurisdiction/content scope.
4. For disconnected environments, use the approved signed offline workflow.
5. Test behavior for an unavailable or invalid entitlement in non-production where practical.

How you know it worked

• The server reports the intended licensed capabilities.
• Evidence and recovery access are not dependent on a hidden cloud heartbeat.

When would I use this?

Run before onboarding production applications or personal data.

What you need before you start

• Customer SSO working
• Approved organisation/legal-entity information

What to do

1. Create or review the organisation and legal-entity profile.
2. Configure business-unit or operating scopes supported by the release.
3. Assign platform and privacy roles using customer identity groups/claims.
4. Confirm maker-checker or segregation-of-duties constraints for governed actions.
5. Verify that users see only the permitted administrative and privacy functions.

How you know it worked

• Organisation identity is correct.
• Roles are least-privilege.
• A prohibited self-approval path is not available.

When would I use this?

Use for initial country/regulatory setup and controlled content updates.

What you need before you start

• Signed content bundle
• Entitlement
• Customer approval owner

What to do

1. Import the signed content pack and verify provenance and compatibility.
2. Review the version, effective-date context and included jurisdiction/content scope.
3. Stage and validate the candidate without changing production decisions.
4. Where available, review the simulation/diff for the current environment.
5. Obtain the required authorized approval.
6. Activate the exact approved version and retain the audit/evidence record.

How you know it worked

• The active version matches the approved signed candidate.
• Historical evidence remains linked to the version in effect when it was created.

When would I use this?

Use before integrating a production web, mobile, API, branch or assisted channel.

What you need before you start

• Application owner
• Purpose/processing context
• Approved integration pattern

What to do

1. Create the application/channel profile and record the accountable owner.
2. Bind the exact application identity, web origin, API/workload identity or mobile app identity as applicable.
3. Link relevant purposes, processing activities, data categories and recipients.
4. Bind the approved notice/consent configuration where consent applies.
5. Configure required API, SDK or connector credentials.
6. Run activation/readiness tests before enabling production traffic.

How you know it worked

• The application is uniquely identifiable.
• The intended purpose/data scope is visible.
• Activation prerequisites pass.

When would I use this?

Use when business systems or directories provide subject identifiers.

What you need before you start

• Defined subject identifiers
• Approved data-minimisation mapping

What to do

1. Define the source system and identifier type.
2. Map only required subject attributes and provenance.
3. Configure source authentication and least-privilege access.
4. Run a bounded import/synchronization.
5. Review duplicate, ambiguous, renamed or recycled identifiers.
6. Confirm identity resolution before using a subject for high-impact rights or consent actions.

How you know it worked

• Source-qualified identifiers are preserved.
• Ambiguous identities are not silently merged.

When would I use this?

Use when processing depends on consent or customer preferences.

What you need before you start

• Approved purposes and data scope
• Published notice content
• Application identity

What to do

1. Create the notice/version and bind language, channel, purpose and effective context.
2. Configure consent purposes and the exact data/processing scope.
3. Integrate the application using the supported API/SDK/channel method.
4. Test grant, evaluate, preference change and withdrawal.
5. Confirm that missing, expired or scope-mismatched proof does not produce a false positive decision.
6. Test downstream withdrawal/cessation propagation and acknowledgement handling where configured.

How you know it worked

• Consent history is versioned and scoped.
• A decision cannot be reused for a different purpose or data scope.
• Withdrawal changes subsequent decisions as designed.

When would I use this?

Use for websites, native apps, kiosks, branches, call centres or deferred/offline capture.

What you need before you start

• Approved channel profile
• Application identity
• Notice/consent configuration

What to do

1. Bind each channel to the correct application and notice/consent configuration.
2. Validate web origin/app identity and supported locales.
3. For assisted capture, preserve operator identity and channel evidence.
4. For offline/deferred capture, keep grants pending until identity, notice and server evidence are reconciled.
5. Prioritize withdrawals for reconciliation; do not treat a local pending state as completed authority.
6. Test retry/idempotency behavior under intermittent connectivity.

How you know it worked

• All channels resolve to the same governed subject/consent history.
• Offline conditions do not fabricate an affirmative grant.

When would I use this?

Use where the licensed deployment includes cookie/tracker governance.

What you need before you start

• Approved website/domain scope
• Consent categories/purposes
• Web application owner

What to do

1. Register the governed website/domain and approved scan scope.
2. Run the supported tracker/cookie discovery process.
3. Classify observed technologies by vendor, purpose and category.
4. Configure the banner/preference experience and versioned content.
5. Configure pre-consent blocking, opt-out or preference enforcement where required by the selected policy.
6. Test first visit, consent change, withdrawal/opt-out and new-tracker detection.
7. Record exceptions and unresolved/unknown trackers for review.

How you know it worked

• Observed trackers are mapped to the intended categories.
• Preference changes alter tracking behavior where enforcement is configured.
• Unknown/new tracking remains visible.

When would I use this?

Use before relying on RoPA, rights search, retention, transfer or reporting outputs.

What you need before you start

• Application inventory
• Business owners
• Known processing activities

What to do

1. Register systems/assets and accountable owners.
2. Record processing activities, purposes, data categories and subject groups.
3. Map collection, use, storage, sharing, transfers, archival and erasure paths.
4. Link processors/recipients and processing locations.
5. Use supported discovery/classification inputs to enrich the inventory where enabled.
6. Keep inaccessible, stale, partial or unknown coverage visible until resolved.
7. Generate or review RoPA outputs from the governed inventory.

How you know it worked

• Key processing activities have owner, purpose, data and location context.
• Unknown links are visible rather than treated as complete.

When would I use this?

Use before accepting production rights or grievance cases.

What you need before you start

• Approved right types/process
• Identity verification process
• Fulfilment owners

What to do

1. Configure supported intake channels and case routing.
2. Define identity/authorized-representative verification requirements.
3. Map fulfilment tasks to systems, processors and owners.
4. Configure response templates, secure delivery and exception/rejection reasons where applicable.
5. Test access/correction/erasure or other rights applicable to the enabled content.
6. Confirm closure is blocked until mandatory downstream actions/evidence are complete.

How you know it worked

• A case can be received, verified, fulfilled and evidenced end to end.
• Required downstream acknowledgements remain visible until resolved.

When would I use this?

Use where third parties process personal data for the customer.

What you need before you start

• Processor inventory
• Agreement/contract ownership

What to do

1. Register processors/subprocessors and accountable contacts.
2. Link purposes, data categories, systems and processing locations.
3. Attach or reference the applicable DPA/contract and version.
4. Configure assessment, renewal, incident, deletion or other required follow-up.
5. Test downstream task and acknowledgement tracking.
6. Keep document extraction/AI assistance subject to accountable human approval.

How you know it worked

• Processor records are linked to actual processing context.
• Required acknowledgements and exceptions are evidence-backed.

When would I use this?

Configure before the system is relied on for live incident handling.

What you need before you start

• Incident-response owners
• Notification approval process
• Enabled regulatory/privacy content

What to do

1. Define incident roles, severity/routing and evidence collection responsibilities.
2. Confirm the active regulatory/privacy content used to evaluate applicable obligations.
3. Configure notification/report templates and required approval paths.
4. Test incident creation, scope changes, child obligations/deadlines and review states.
5. Test manual export/notification paths where automated connectors are unavailable.
6. Run a simulation without sending live notifications.

How you know it worked

• Independent obligations retain their own source and due-time context.
• Transport success cannot automatically become regulator acknowledgement or legal closure.

When would I use this?

Use where the enabled scope includes privacy impact or risk assessment.

What you need before you start

• Assessment owner
• Approved template/methodology
• Evidence sources

What to do

1. Select the approved assessment template and scope.
2. Link the application/process, purpose, data, recipients and relevant evidence.
3. Assign respondents and reviewers.
4. Record findings, treatment, residual risk and approvals.
5. Retain methodology/template version and supporting evidence.
6. Reassess after material change or evidence expiry.

How you know it worked

• Assessment conclusions are linked to evidence and accountable reviewers.
• A numeric score is not treated as proof of compliance.

When would I use this?

Run after install, major upgrade, restore or topology promotion.

What you need before you start

• Commissioning complete

What to do

1. Validate DNS and TLS from actual user and service network zones.
2. Confirm trusted time across participating nodes.
3. Confirm database, evidence storage and key-service readiness.
4. Test customer SSO, least-privilege roles and denied access.
5. Run a representative application/consent or governed workflow.
6. Verify audit/evidence creation.
7. Run backup/recovery validation appropriate to the selected profile.

How you know it worked

• No required dependency remains degraded or unknown.
• Representative workflows succeed without bypassing security controls.

When would I use this?

Use for UAT and production-readiness review.

What you need before you start

• Agreed acceptance scope
• Test identities/data

What to do

1. Test application onboarding and authorization boundaries.
2. Test notice publication, consent capture, evaluation, preference change and withdrawal where used.
3. Test a rights case from intake to evidence-backed closure.
4. Test processor/downstream acknowledgement where used.
5. Test incident simulation and report/evidence generation where used.
6. Test cookie/tracker behavior where enabled.
7. Test unavailable, stale, partial or unknown conditions to ensure they do not appear as successful states.
8. Record findings and retest corrected items.

How you know it worked

• All critical production journeys pass using the deployed configuration.
• Negative/fail-closed behavior is tested, not assumed.

When would I use this?

Required before go-live for production profiles and after material resilience changes.

What you need before you start

• Working backup
• Recovery procedure
• HA/DR runbook where applicable

What to do

1. Create and verify a fresh backup and required WAL/archive state.
2. Restore into the approved test/recovery target.
3. Reconnect key/evidence dependencies and validate integrity/readiness.
4. For HA, perform controlled database/application failover.
5. For DR, fence the prior writer/site before promotion and reconcile freshness before failback.
6. Verify representative governed data and evidence after recovery.
7. Record measured recovery results.

How you know it worked

• Recovered state is internally consistent.
• No stale member/site can write.
• Evidence objects and database state are both recoverable.

When would I use this?

Run as the final security checkpoint before go-live.

What you need before you start

• Security review
• Operational runbooks

What to do

1. Verify non-essential network paths are blocked.
2. Verify privileged access, maker-checker and break-glass controls.
3. Verify secrets and private keys are not stored in ordinary application configuration or logs.
4. Verify direct browser/integration database access is absent.
5. Review log/telemetry fields for unnecessary personal data, tokens and secrets.
6. Confirm certificate, backup, patching, monitoring and incident owners.
7. Confirm support-bundle/export procedures require customer authorization.

How you know it worked

• No open critical security finding remains for the agreed production scope.
• Operational owners and runbooks are in place.

When would I use this?

Use for daily operations and incident triage.

What you need before you start

• Customer monitoring destination where used

What to do

1. Monitor liveness and readiness separately.
2. Alert on database, storage, key services, clock, queue/deadline and integration conditions relevant to your profile.
3. Keep operational logs separate from the immutable audit/evidence record.
4. Export only privacy-minimized metrics/logs to approved monitoring systems.
5. Investigate readiness reason codes before restarting services.
6. Treat optional telemetry outages as observability incidents, not automatic authority failure.

How you know it worked

• Operations can distinguish live, ready, degraded and blocked conditions.
• Logs do not contain raw secrets or unnecessary personal data.

When would I use this?

Use for scheduled production backup and recovery planning.

What you need before you start

• Retention policy
• Backup target
• Recovery owner

What to do

1. Back up PostgreSQL using the supported method and enable continuous archive/WAL where required.
2. Back up evidence/object data and required release/content references.
3. Protect backup credentials and key-recovery references.
4. Monitor backup and archive freshness.
5. Run scheduled restore tests.
6. Retain test evidence and remediate any unverified recovery dependency.

How you know it worked

• Backup jobs succeed and failures alert.
• Restore testing proves usable state, not only readable files.

When would I use this?

Use for recovery tests and real incidents.

What you need before you start

• Approved restore point
• Recovery authorization

What to do

1. Declare recovery and fence any former writer or stale site where applicable.
2. Restore PostgreSQL and evidence/object data using the approved procedure.
3. Reconnect customer key services and required trust anchors.
4. Run release-supplied schema/content/evidence verification.
5. Validate representative governed records and evidence integrity.
6. Confirm topology/site freshness before allowing production writes.
7. Record the recovery result and any gaps.

How you know it worked

• Recovered services are ready, not merely running.
• Stale or uncertain members remain fenced.

When would I use this?

Use for planned maintenance or HA incidents.

What you need before you start

• Supported HA profile
• Fencing/quorum healthy

What to do

1. Identify the current authoritative database leader and coordination state.
2. Confirm the former/unsafe primary can be fenced.
3. Promote only under the supported quorum conditions.
4. Confirm TrustPlane writes target the new leader only.
5. Keep the former primary fenced until it is reconciled/reseeded.
6. Run a representative governed write and evidence check after failover.

How you know it worked

• Exactly one writer exists.
• Application readiness follows the new authority.
• Former primary cannot accept authoritative writes.

When would I use this?

Use for multi-site or DR profiles.

What you need before you start

• DR runbook
• Site fencing mechanism
• Replication/backup status

What to do

1. Declare the DR event and identify the last authoritative site/generation.
2. Fence the old writer/site.
3. Restore or activate the recovery site.
4. Validate database, evidence, active content versions, entitlements, keys and clock.
5. Enable ingress only after the recovery site is ready for writes.
6. Before failback, reconcile or reseed the returning site and repeat readiness checks.

How you know it worked

• The promoted site is current and authoritative.
• A stale site cannot rejoin as a writer.

When would I use this?

Use for patches and version upgrades.

What you need before you start

• Verified update bundle
• Compatibility manifest
• Verified backup

What to do

1. Verify package identity, provenance and compatibility.
2. Run the release preflight and confirm backup/recovery readiness.
3. Apply release-supplied migrations; never edit already-applied migration history.
4. Upgrade services within the supported mixed-version window, if one exists.
5. Run post-upgrade readiness and representative workflow tests.
6. Rollback only when the release documentation declares it safe; otherwise follow the supported restore-forward/remediation path.

How you know it worked

• The environment is on the intended software/schema version.
• Post-upgrade tests and evidence pass.

When would I use this?

Use for planned PKI maintenance or certificate incidents.

What you need before you start

• New certificate/trust material
• Change window

What to do

1. Inventory certificate consumers and expiry dates.
2. Stage new trust/intermediates where overlap is required.
3. Issue the replacement certificate with the correct names and usage.
4. Deploy/reload using the supported procedure.
5. Verify client and server paths.
6. Retire/revoke the old material after the approved overlap and record the new fingerprint/expiry.

How you know it worked

• All intended peers validate the new certificate.
• No old certificate remains unintentionally active.

When would I use this?

Use when retiring or replacing an environment.

What you need before you start

• Approved decommission plan
• Retention/legal-hold review

What to do

1. Stop new production intake at the approved point.
2. Create and verify required final exports/evidence.
3. Revoke integration credentials, IdP clients, certificates and service accounts.
4. Apply retention/legal-hold requirements to database, evidence and backups.
5. Confirm key-retirement dependencies before destroying key material.
6. Remove workloads and firewall rules.
7. Retain the decommission record and evidence.

How you know it worked

• No active integration can continue using the retired environment.
• Required records remain accessible for their approved retention period.

When would I use this?

Use for any unexplained production or integration symptom.

What to do

1. Capture UTC time, affected screen/action, stable error code and correlation/request ID.
2. Record the exact release, deployment profile and recent change.
3. Check liveness and readiness plus database, storage, key service, clock, content and entitlement dependencies.
4. Check the specific network/TLS/identity/connector path involved.
5. Reproduce with the minimum necessary test data.
6. Apply the documented remediation; if unresolved, prepare a privacy-safe support package.

How you know it worked

• The problem statement includes time, release, path and correlation information.
• Troubleshooting did not weaken security or authority controls.

When would I use this?

Use for timeout, connection-refused and TLS errors.

What you need before you start

• Source host/pod/zone
• Target FQDN/service

What to do

1. Resolve the target name from the actual source.
2. Confirm the resolved IP/VIP is expected.
3. Test the exact configured TCP/UDP port.
4. Validate the TLS chain, hostname and negotiated protocol where applicable.
5. Check host firewall, security group, NetworkPolicy and load-balancer readiness.
6. Confirm the flow exists in the approved firewall matrix.

How you know it worked

• The network test is run from the correct source zone.
• A successful port test is followed by TLS/application validation.

When would I use this?

Use for login failures, HTTP 401/403 and missing actions.

What to do

1. Check DNS, time and TLS to the IdP.
2. Validate issuer/entity ID, audience, redirect URL and signing trust.
3. Confirm the user/group claims received by the server.
4. Check TrustPlane role mapping, scope and entitlement.
5. Check maker-checker or state prerequisites for the requested action.
6. Retest with a known authorized and a known unauthorized user.

How you know it worked

• The root cause is identified as authentication, authorization, entitlement or workflow state.
• No frontend-only bypass is used.

When would I use this?

Use when writes are blocked, database authority is unavailable or an HA member is stale.

What to do

1. Identify the current database leader and coordination/quorum state.
2. Check database TLS, credentials, schema and leader service routing.
3. Check fencing status before any manual promotion.
4. For a returning member/site, compare data and topology freshness and reseed/reconcile if required.
5. Confirm application readiness only after write authority is unambiguous.
6. Run a controlled write/evidence test after remediation.

How you know it worked

• Exactly one valid write authority exists.
• A stale member remains blocked until reconciled.

When would I use this?

Use when dashboards or integrations show an unfamiliar state.

What to do

1. Treat UNKNOWN as a required fact that is not yet known.
2. Treat PARTIAL as incomplete scope or coverage.
3. Treat STALE as evidence/observation outside the expected freshness window.
4. Treat REVIEW REQUIRED as a governed human decision still needed.
5. Keep SENT/ACCEPTED, DELIVERED and ACKNOWLEDGED distinct.
6. Use the server error/correlation ID in troubleshooting and support.

How you know it worked

• Unknown/partial/stale conditions remain visible.
• Transport acceptance is not presented as legal or workflow closure.

Reference details

When would I use this?

Use during commissioning, renewal, country-pack enablement or a commercial scope change.

What you need before you start

• Signed entitlement material for the exact deployment
• Approved customer scope

What to do

1. Import the signed entitlement material through the administration workflow.
2. Review named country, feature, sector and duration scope; do not treat a regional bundle as a wildcard legal mode.
3. Verify the entitlement generation and deployment binding before activating dependent content.
4. For disconnected deployments, perform the same verification using the approved offline workflow.
5. Review any exposure gap where an operational context refers to a country or capability that is not entitled.
6. Retain the entitlement change and approval record with the deployment evidence.

How you know it worked

• The server reports the exact intended scope.
• Direct API, job and report paths cannot bypass entitlement checks.
• An unlicensed country does not silently activate detailed legal execution.

When would I use this?

Use when processing, data location, establishment, subject or transaction context can engage more than one jurisdiction.

What you need before you start

• Applicable signed country packs
• Trusted deployment and processing facts

What to do

1. Configure the authoritative facts used by the applicability engine, including customer, processing, subject, location and transaction context where relevant.
2. Review candidate jurisdictions and any source-qualified threshold facts.
3. Resolve missing mandatory facts rather than defaulting them to not-applicable.
4. Preserve independent obligation branches when more than one jurisdiction component applies.
5. Review applicability decisions together with the pack version and source facts that produced them.
6. Treat UI geolocation, browser language and campaign targeting as hints only; they must not establish legal applicability.

How you know it worked

• A caller cannot force a jurisdiction by changing browser or request parameters.
• Unknown mandatory facts fail safely or require review.
• Multiple applicable components retain separate provenance.

When would I use this?

Use when creating administrative, privacy, audit, support or integration access.

What you need before you start

• Customer identity provider working
• Approved role and attribute model

What to do

1. Map IdP groups or claims to the minimum TrustPlane roles required.
2. Register only trusted attribute issuers for ABAC inputs such as legal entity, region, function or case ownership.
3. Configure row/object scope and field masking for sensitive or protected data.
4. Test both permitted and denied access from the API as well as the user interface.
5. Test role/attribute changes and revocation.
6. Review service identities separately from human administrator identities.

How you know it worked

• Server responses do not return fields hidden only by the UI.
• A user cannot expand scope by manipulating a client-side attribute.
• Denied actions are recorded with useful reason codes.

When would I use this?

Use when an application must validate processing authority before a protected action.

What you need before you start

• Application and purpose registered
• Relevant pack/consent/authorization context
• TrustPlane signing/key service ready

What to do

1. Define the protected processing activity, purpose/sub-purpose, data scope and action.
2. Bind the application/workload identity that may request the decision.
3. Evaluate pack applicability, entitlement, authorization and consent or other required authority.
4. Issue the scoped decision proof only after the server reaches an authoritative decision.
5. Validate proof expiry and generation bindings so stale entitlement, policy or withdrawal state cannot be reused.
6. Require a fresh decision when the purpose, data scope, action, subject or controlling authority changes.

How you know it worked

• A proof cannot be reused for a different purpose or data scope.
• Withdrawal or relevant policy generation changes invalidate stale authority.
• Offline/no-store behavior follows the configured fail-safe policy.

When would I use this?

Use for notices, forms, emails, reports and other regulated customer content.

What you need before you start

• Signed content pack
• Approved source/legal content
• Language owners

What to do

1. Create or import the localized artifact and record language, version, digest and effective dates.
2. Complete translation/business review and the required legal/content approval.
3. Bind notice content to the exact application, channel, purposes, data scope and active pack components.
4. Require the exact approved locale where the pack/profile says it is mandatory.
5. Validate accessibility and directionality for UI, forms, tables, PDFs and email where applicable.
6. Supersede old content without rewriting historical evidence.

How you know it worked

• Published content is linked to an approved immutable version.
• A missing mandatory locale does not silently fall back to English.
• Historical transactions can be reconstructed against the content version shown at the time.

When would I use this?

Use for branch, field, assisted, kiosk or other channels that can temporarily lose connectivity.

What you need before you start

• Approved offline/deferred channel profile
• Notice and consent configuration

What to do

1. Configure the signed offline capture format and local expiry/replay controls.
2. Capture the subject, notice, purpose, data scope and channel evidence required by the profile.
3. Treat the local record as pending until server reconciliation succeeds.
4. On reconnect, validate subject identity, notice version, time, replay state and applicable policy.
5. Resolve conflicts explicitly and prioritize withdrawals or more restrictive states.
6. Persist the authoritative result and retain reconciliation evidence.

How you know it worked

• A stale or replayed offline record cannot create a fresh grant.
• A pending local record is not presented as completed server authority.
• Withdrawal/restriction conflicts are resolved conservatively.

When would I use this?

Use for existing-customer notices, material notice updates or governed re-consent campaigns.

What you need before you start

• Approved campaign scope
• Versioned notice/content
• Subject source and deduplication keys

What to do

1. Define the campaign population and authoritative source.
2. Bind the exact notice/content version, purposes and effective context.
3. Preview and deduplicate recipients before activation.
4. Dispatch through approved channels and retain transport identifiers separately from response state.
5. Ingest responses idempotently and link them to the subject and notice version.
6. Track unreachable, pending, declined, withdrawn and other non-success states explicitly.

How you know it worked

• Duplicate source rows do not create duplicate authoritative grants.
• Transport delivery does not fabricate consent.
• Campaign evidence identifies the exact population, content version and dispatch result.

When would I use this?

Use when the licensed customer scope includes India DPDP operations.

What you need before you start

• India country entitlement
• Signed India pack
• Customer legal/applicability owner

What to do

1. Import and verify the signed India pack and dependencies.
2. Review the pack version, source provenance, effective-date metadata and enabled language/sector extensions.
3. Activate the pack through the required approval workflow.
4. Configure customer entities, applications and processing activities that may require India evaluation.
5. Review applicability outcomes before publishing notices, rights workflows or reports.
6. Retain the exact pack version in subsequent evidence and reporting.

How you know it worked

• India content is active only for an entitled deployment.
• Activation is not treated as automatic legal applicability.
• Historical evidence keeps the pack/version in force at the time.

When would I use this?

Use when configuring a customer operating as a Data Fiduciary for in-scope India processing.

What you need before you start

• India pack active
• Processing inventory and owners
• Approved notice/purpose model

What to do

1. Map the relevant legal entities, applications, processing activities, purposes and personal-data categories.
2. Configure the approved India notice and consent/preference experience where consent is used.
3. Connect withdrawal/cessation flows to downstream systems and processors.
4. Register processors and evidence the applicable contracts, actions and acknowledgements.
5. Configure grievance and incident routing to the accountable customer owners.
6. Validate reports against the evidence produced by these workflows.

How you know it worked

• Purpose/data scope and notice lineage are visible.
• Withdrawal changes subsequent processing decisions where configured.
• Processor, grievance and incident actions remain evidence-backed.

When would I use this?

Use before exposing Data Principal self-service or assisted rights channels.

What you need before you start

• India pack active
• Identity verification process
• Fulfilment owners

What to do

1. Enable the supported India rights and grievance case types from the active pack.
2. Configure identity and authorized-representative verification appropriate to the channel and risk.
3. Map fulfilment tasks to authoritative systems and processor targets.
4. Configure secure communication, response and escalation templates.
5. Configure nomination details and authority checks where the workflow is used.
6. Test a case from intake through evidence-backed closure, including unresolved-target behavior.

How you know it worked

• Cases cannot close while mandatory evidence or target actions remain unresolved.
• Erasure follows pack applicability and bounded exceptions rather than a universal delete-all rule.
• Nomination/representation authority is recorded and reviewable.

When would I use this?

Use for processing involving children where guardian/parental authority is part of the approved workflow.

What you need before you start

• India pack active
• Age/guardian verification policy
• Approved consent model

What to do

1. Configure the subject-age and guardian relationship evidence required by the customer policy.
2. Apply data minimisation to the evidence collected for age/guardian verification.
3. Bind the guardian authority to the relevant child, purpose, application and effective period.
4. Prevent a guardian credential from becoming unrestricted authority over unrelated subjects or purposes.
5. Handle expiry, correction or revocation of the relationship explicitly.
6. Retain the proof and decision lineage used for the governed action.

How you know it worked

• Guardian authority is subject- and purpose-bounded.
• Missing mandatory verification does not become an affirmative decision.
• The workflow can be reconstructed from evidence.

When would I use this?

Use when the customer chooses to integrate TrustPlane with a registered Consent Manager.

What you need before you start

• India pack active
• Approved Consent Manager integration endpoint
• Customer integration agreement

What to do

1. Register the Consent Manager integration as an external system with a distinct service identity.
2. Configure the supported authenticated API/adapter and least-privilege data scope.
3. Map external consent identifiers to TrustPlane subject, purpose and application context without creating duplicate authority.
4. Reconcile grants, reviews and withdrawals using versioned, idempotent exchange.
5. Keep transport state separate from authoritative consent state and any external acknowledgement.
6. Audit each exchange and reconciliation result.

How you know it worked

• The integration cannot mint consent without the required evidence.
• External identifiers preserve source provenance.
• Withdrawals and conflicts are reconciled explicitly.

When would I use this?

Use where the customer has determined that additional Significant Data Fiduciary obligations apply.

What you need before you start

• India pack active
• Customer applicability decision
• DPO/oversight owners

What to do

1. Record the customer applicability decision and responsible owners.
2. Configure the DPO/oversight contact and evidence responsibilities.
3. Create DPIA/privacy assessment workflows with the approved methodology and evidence sources.
4. Schedule audits, control reviews and remediation tracking.
5. Link findings to owners, due dates, treatment and verification evidence.
6. Generate the corresponding pack-aware management and audit outputs.

How you know it worked

• Assessment and audit outputs identify methodology/version and evidence.
• Outstanding remediation remains visible.
• TrustPlane does not self-designate the customer as a Significant Data Fiduciary.

When would I use this?

Use when multilingual India customer communications are enabled.

What you need before you start

• India pack active
• Licensed/configured language profile
• Approved translations

What to do

1. Enable the customer-approved India language profile.
2. Import or create the translated artifacts and retain source/translation version lineage.
3. Complete human/legal approval for each language required by the profile.
4. Bind the locale to the correct notice, channel and effective interval.
5. Validate forms, PDFs, email and assistive-technology presentation.
6. Block publication where the profile requires an approved locale that is missing.

How you know it worked

• Each effective translation has its own digest/version and approval.
• Language changes do not overwrite historical notice evidence.
• No mandatory locale silently falls back to another language.

When would I use this?

Use when the customer has licensed a supported India sector overlay.

What you need before you start

• India pack active
• Relevant sector entitlement
• Signed overlay

What to do

1. Import and verify the signed sector overlay.
2. Review dependencies, effective dates and customer applicability.
3. Activate the overlay through the governed approval workflow.
4. Review additional templates, assessments, controls, evidence and reporting fields.
5. Validate that the overlay uses the same shared subject, consent, rights and evidence services.
6. Retest affected workflows and reports.

How you know it worked

• Overlay activation is entitlement- and approval-controlled.
• India baseline behavior is not silently weakened.
• Reports show the overlay/version that contributed to the result.

When would I use this?

Use for management, privacy office, audit, assurance or regulator-facing preparation.

What you need before you start

• India pack active
• Reporting scope approved
• Required evidence present

What to do

1. Select the India report and the customer/legal-entity scope.
2. Choose the reporting period and applicable pack/content version context.
3. Review control results, evidence references, gaps, exceptions, owners and remediation state.
4. Add the customer logo and approved report identity metadata.
5. Generate the supported HTML, Word or PDF output.
6. Verify that generation date/time and the logged-in generating user are recorded.

How you know it worked

• Every conclusion links back to governed evidence or an explicit gap.
• The report identifies scope, pack/version, generation time and generating user.
• Different output formats present the same underlying facts.

When would I use this?

Use when building or refreshing the data estate, rights target graph or processing inventory.

What you need before you start

• Approved discovery scope
• Credentials with least-privilege access
• Classification policy

What to do

1. Define the structured/unstructured discovery scope and safety limits.
2. Run supported customer-local discovery against approved sources.
3. Record coverage, inaccessible, partial and stale states explicitly.
4. Reconcile TrustPlane findings with customer declarations, catalogues or optional third-party classifications.
5. Preserve source lineage and conflicts rather than overwriting stronger or contradictory evidence.
6. Publish accepted observations into the governed estate/lineage model.

How you know it worked

• Coverage gaps remain visible.
• Every accepted classification retains source provenance.
• An optional external catalogue is not required for TrustPlane authority.

When would I use this?

Use for pre-production validation, periodic assurance or remediation verification.

What you need before you start

• Approved test scope
• Non-production or controlled test identities/data

What to do

1. Select the application and journey to inspect.
2. Run the supported browser, API or assisted journey evidence workflow.
3. Review detected personal-data fields, notices, choices, trackers, versions and other configured findings.
4. Classify findings as reviewed, accepted or rejected and link remediation where required.
5. Re-run the journey after remediation.
6. Mark the finding verified only when the configured evidence supports it.

How you know it worked

• Automated findings cannot publish a notice, grant consent or decide applicability.
• Findings retain their evidence and review history.
• Re-test evidence is linked to the remediation.

When would I use this?

Use where sensitive/demographic attributes are present in source data or assurance workflows.

What you need before you start

• Approved attribute profile and purpose
• Customer data-minimisation policy

What to do

1. Define the permitted attribute profile and the exact purpose for which each field is needed.
2. Filter unnecessary fields at acquisition before persistence wherever feasible.
3. Use references, categories, hashes or derived values instead of raw values where the use case permits.
4. Apply server-side projection/masking to API, UI, search, export and report surfaces.
5. Review logging, diagnostics and integration payloads for accidental exposure.
6. Set retention/review rules for the minimum required attribute evidence.

How you know it worked

• Disallowed raw values do not appear in ordinary logs, diagnostics or reports.
• UI masking is backed by server projection.
• Fields outside the approved purpose are suppressed.

When would I use this?

Use where high-impact decisions, proxy-risk analysis or fairness assurance is enabled.

What you need before you start

• Approved decision-feature inventory
• Assurance purpose
• Protected-attribute controls

What to do

1. Register the decision feature and the data features it is permitted to use.
2. Default-deny undeclared or newly introduced decision features.
3. Create a purpose-isolated assurance workset for fairness/proxy-risk analysis.
4. Apply minimum cohort and small-group protection rules.
5. Review findings and remediation without exposing protected data to the operational decision path.
6. Retest after material model, feature or population change.

How you know it worked

• Protected attributes used for assurance are not reused by the operational decision without separate authority.
• Undeclared decision features are blocked or escalated.
• Small-cohort outputs are suppressed or controlled according to policy.

When would I use this?

Use for a supported erasure/deletion right after identity and applicability have been resolved.

What you need before you start

• Verified rights case
• Target-discovery graph
• Retention/legal-hold authority where applicable

What to do

1. Evaluate whether the erasure right applies using the active pack and case facts.
2. Create a disposition for each in-scope target: erase, retain under bounded exception, review required or another supported state.
3. Execute erasure idempotently across primary, replica/projection, cache/index, derived/export and processor targets.
4. Require processor/subprocessor proof or a governed exception rather than treating transport success as deletion proof.
5. Apply tombstone/restriction logic so a later restore does not silently resurrect ordinary use.
6. Issue completion evidence only when all mandatory targets are resolved.

How you know it worked

• Unresolved targets prevent a false COMPLETE state.
• Exceptions identify source, scope, approval and review/expiry.
• Restore testing proves retained tombstones/restrictions are reapplied.

When would I use this?

Use for cross-border transfers, regional services, backups, DR, key services or administrative access from another geography.

What you need before you start

• Known data/processing locations
• Relevant licensed country packs
• Approved topology

What to do

1. Record source and destination processing/storage locations using trusted facts.
2. Treat an unknown mandatory location as unresolved rather than assuming transfer is permitted.
3. Confirm that detailed destination evaluation is supported by an entitled active country pack.
4. Evaluate the pack-defined conditions and required controls.
5. Check storage, backup, DR, key, admin and telemetry placement against sovereignty policy.
6. Retain the transfer decision, controlling facts and evidence.

How you know it worked

• An unknown mandatory destination cannot produce a positive authority decision.
• HA/DR does not replicate protected data into a prohibited location for convenience.
• Transfer decisions retain pack and fact provenance.

When would I use this?

Use when one incident can affect subjects, systems, processors or countries under more than one regulatory regime.

What you need before you start

• Incident scope established
• Relevant packs active
• Incident owners

What to do

1. Create or update the single incident truth with systems, data, subjects, processors, countries and chronology.
2. Run applicability to instantiate the relevant obligation branches.
3. Track due times, required content, approvals and recipients separately per branch.
4. Use simulation mode when testing; simulation must not send live notifications.
5. Distinguish prepared, sent, transport-accepted, delivered, acknowledged and legally closed states.
6. Update branches when the incident scope materially changes.

How you know it worked

• A single incident does not create duplicate competing incident records.
• One branch cannot close another independent obligation.
• Simulation has a hard no-send path.

When would I use this?

Use when adding pack requirements, assurance evidence or cross-regime reporting.

What you need before you start

• Applicable signed regulatory/framework content
• Evidence owners

What to do

1. Resolve the applicable requirement from the active pack and authority version.
2. Map the requirement to the canonical control identifiers used across TrustPlane.
3. Attach or reference the required evidence using stable evidence identities.
4. Record evidence state, freshness, provenance and any deficiency.
5. Map remediation, owner and verification state without rewriting source evidence.
6. Use report projections from this shared semantic model.

How you know it worked

• The same control/evidence identities appear consistently across views and report formats.
• Historical reports can reconstruct the authority/version in force at the time.
• A new pack does not create a shadow reporting database.

When would I use this?

Use when importing evidence, defining report fields or adding an integration source.

What you need before you start

• Defined evidence purpose
• Active pack/control requirements

What to do

1. Identify the control or reporting purpose for the evidence.
2. Evaluate which source fields are required, conditional or prohibited for that purpose.
3. Prefer governed pointers, hashes or references when copying the source value is unnecessary.
4. Suppress non-required fields before persistence or export where feasible.
5. Apply the same minimisation policy to web, Word, PDF, API/JSON and other outputs.
6. Review retention and freshness requirements for the remaining evidence.

How you know it worked

• Evidence stores do not contain unrelated source payload by default.
• Report/export formats do not reintroduce suppressed fields.
• Necessity decisions are auditable.

When would I use this?

Use when SBOM/CBOM/QBOM/AIBOM/HBOM or similar evidence is provided by customer tooling or an approved third party.

What you need before you start

• Supported source format
• Approved evidence purpose
• Applicable control/framework requirements

What to do

1. Import the supported BOM artifact through the governed evidence adapter.
2. Validate format, size, schema and signatures/attestations where present.
3. Preserve the original source identity and provenance for every normalized field or derived calculation.
4. Apply field-level necessity/minimisation before persistence and reporting.
5. Map relevant evidence to canonical controls and retain conflicts or weaker evidence states visibly.
6. Review freshness/drift and reassessment triggers after material BOM changes.

How you know it worked

• Imported evidence cannot silently override stronger verified evidence.
• Each mapped field can be traced to source or an explicit derivation.
• BOM-specific views are projections of the shared evidence model.

When would I use this?

Use for management reporting, audits, assurance, customer evidence exchange or regulator preparation.

What you need before you start

• Reporting scope
• Applicable pack/framework
• Required evidence state

What to do

1. Choose the report family and organisation/legal-entity scope.
2. Resolve the active pack/framework manifest and reporting period.
3. Review applicability, controls, evidence, deficiencies, remediation and verification state.
4. Apply customer branding and approved presentation settings.
5. Generate the supported interactive/web, Word and PDF output; use other enabled formats where the specific report supports them.
6. Retain stable control/evidence IDs, pack versions, generation time and generating user.

How you know it worked

• All formats derive from one governed report/evidence model.
• Missing or stale evidence remains visible in the output.
• A report does not rewrite operational evidence.

When would I use this?

Use before go-live and after a material release upgrade.

What you need before you start

• Exact candidate build
• Acceptance matrix
• Customer environment

What to do

1. Record the exact software/package hashes and database schema/migration state.
2. Record the installed pack/content versions, key security profile and relevant configuration identity.
3. Execute the approved functional, security, resilience, migration and negative tests for the selected profile.
4. Record every deviation as a defect or explicit disposition rather than quietly modifying the acceptance result.
5. Re-run affected acceptance tests after remediation.
6. Retain the evidence index with the deployment change/go-live record.

How you know it worked

• Acceptance evidence maps to the exact deployed candidate.
• A remediated build is re-tested rather than inheriting a previous pass.
• No customer-facing claim depends only on an internal release name.

When would I use this?

Use when a deployment, integration or product workflow requires deeper troubleshooting.

What you need before you start

• Authorized administrator
• Defined problem/time window
• Ticket/reference where applicable

What to do

1. Open the Diagnostics area and choose the relevant problem profile.
2. Select only the required nodes/services and time window.
3. Provide a reason or support reference where required by customer policy.
4. Generate the pack on demand.
5. Review collector status, completeness gaps and the redaction/minimisation summary.
6. Download the package using the policy-bounded download flow.

How you know it worked

• Generation is user-triggered and auditable.
• Collectors do not mutate operational domain state.
• A partial pack identifies its completeness gaps instead of pretending to be complete.

When would I use this?

Use before generating any diagnostic package.

What you need before you start

• Known symptom/failure domain
• Customer support-data policy

What to do

1. Choose the narrowest applicable diagnostic profile and time window.
2. Review the collectors that will run and any privileged collection requirements.
3. Use the configured allowlists, type-aware redaction, truncation, hashing/tokenization and field suppression.
4. Exclude raw sensitive/demographic payload unless it is explicitly necessary and authorized by the profile.
5. Confirm diagnostic resource ceilings so troubleshooting does not starve production privacy operations.
6. Generate the pack only after reviewing the scope.

How you know it worked

• The pack contains metadata/digests/fingerprints by preference over raw business payload.
• Redaction/minimisation decisions are recorded.
• Secrets and TLS private/session keys are not included.

When would I use this?

Use after a diagnostic package has been generated.

What you need before you start

• Completed diagnostic generation

What to do

1. Review package summary, collector results and completeness warnings.
2. Record the package digest and manifest/signature information.
3. Use the short-lived or policy-bounded download token to save the package locally.
4. Apply whole-bundle encryption when required by the customer support-data policy.
5. Confirm that the server-side staged copy is purged after download or the configured short TTL.
6. Store the customer copy according to the support case and retention policy.

How you know it worked

• Every included artifact is hash-bound in the package manifest.
• The package can be verified as untampered before analysis.
• The platform does not silently retain a library of old support bundles.

When would I use this?

Use when TrustPlane support requires the diagnostic package for root-cause analysis.

What you need before you start

• Verified diagnostic package
• Approved support case/channel
• Required package encryption

What to do

1. Use the customer-approved channel to transfer the verified package manually.
2. Do not send decryption secrets or channel credentials inside the diagnostic package.
3. Record the support case/ticket reference and transfer classification.
4. Support intake verifies container version, signature, hashes, schema and redaction metadata before analysis.
5. Support analysis correlates timelines, dependency/node health and versioned deterministic diagnostic rules.
6. Review returned findings together with their evidence references and confidence class.

How you know it worked

• No live customer database/network access is required for standard analysis.
• Tampered or incompatible packages are rejected/quarantined rather than treated as valid evidence.
• Root-cause findings distinguish confirmed, strongly indicated, correlated and insufficient-evidence states.

How requests outside support hours are treated

Unless a customer-specific support agreement states otherwise, a request received outside the published support window is treated as received at the start of the next support window.

Customer-specific agreements

If your order form, support agreement or other governing customer contract provides different support hours, severity handling or response commitments, the contracted terms take precedence over this public guide.