# Compliance & security
Source: https://docs.settlemint.com/docs/business/compliance-security
DALP embeds regulatory controls into transaction execution so regulated asset programmes can enforce eligibility, identity, and transfer rules before state changes settle.
## Key terms [#key-terms]
* **[ERC-3643](/docs/business/glossary#erc-3643)** – Token standard
embedding compliance checks in transfer execution
* **[OnchainID](/docs/business/glossary#onchainid)** – Decentralized
identity protocol for portable investor credentials
* **[HSM](/docs/business/glossary#hsm)** – Hardware Security Module
providing tamper-resistant key storage
* **[Multi-signature](/docs/business/glossary#multi-signature-wallet)**
– Wallet requiring multiple approvals for transactions
## Why institutions need compliance-first architecture [#why-institutions-need-compliance-first-architecture]
Compliance must be foundational, not an afterthought. Traditional securities
have compliance processes that evolved over decades through painful, costly
failures.
Transfer agents verify eligibility before updating ownership records because
regulators mandated it after investors lost money. Custodians enforce security
controls before releasing assets because someone once walked away with millions.
Risk committees approve platforms that demonstrate control, auditability, and
regulatory alignment from day one, not platforms promising to "add compliance
later."
DALP was architected with this reality as the foundational requirement.
Blockchain technology improves traditional processes only when the platform
implements enforceable controls. For regulated assets, the important questions
are practical: can the operator trace decisions, verify identity checks, and
show that transfer rules were evaluated before settlement? DALP treats those
controls as embedded infrastructure rather than optional application logic.
## Regulatory compliance by design [#regulatory-compliance-by-design]
### Compliance happens in the transfer path, not after it [#compliance-happens-in-the-transfer-path-not-after-it]
Every token transfer in DALP executes through compliance checks before any state
changes occur. This isn't a best practice recommendation you can skip under
deadline pressure. It is how the ERC-3643 standard works at the protocol level.
When Alice tries to transfer bond tokens to Bob, the transaction either
completes fully or reverts completely. There's no partial transfer, no "pending
compliance review," no cleanup operation to reverse an improper transaction.
The smart contract verifies whether Alice's wallet links to a verified identity,
whether Bob's wallet links to a verified identity, and whether Bob meets the
specific eligibility requirements for this asset: accreditation status,
jurisdiction restrictions, or institutional qualifications. The system checks
whether the transfer violates holding limits, lockup periods, or concentration
rules that prevent a single investor from dominating ownership. Finally, the
contract confirms no asset-wide restrictions are currently in force, such as
trading halts or emergency freezes imposed by compliance officers.
If any check fails, the transfer reverts immediately. The blockchain state
doesn't change, so there is no "undo" process for the failed transfer, and the
transaction emits a reason code explaining which rule prevented execution. This
ex-ante control gives operators an auditable record of the rule evaluation
before settlement.
For mint operations, the same control model separates the business instruction
from the EVM transaction. Production integrations should send a stable
`Idempotency-Key` for each approved mint instruction, keep the recipient,
amount, asset, executor, and wallet route stable across retries, and reconcile
the transaction status or indexed supply before issuing a replacement mint. See
[Replay protection and mint controls](/docs/compliance-security/security/replay-idempotency-mint-controls)
for the technical retry, nonce, custody-signing, and supply-control details.
### Identity registry and portable credentials eliminate repetitive verification [#identity-registry-and-portable-credentials-eliminate-repetitive-verification]
Investors verify identity once. DALP implements reusable digital identity that
works across all assets an investor is eligible to hold. When an
investor completes KYC/AML verification for one bond offering, that verification
credential carries forward automatically to other investments on the platform.
Investors don't waste time repeating identity checks; their digital identity
accumulates verified credentials from trusted verifiers that travel with them.
Identity credentials are attestations about investor status signed by trusted
verifiers like KYC providers, legal counsel, or regulatory custodians. These
credentials might prove someone completed KYC verification to Level 2 standards
on a specific date, confirm an entity qualifies as an accredited investor under
Regulation D, attest an individual resides in a permitted jurisdiction, or
verify an institution meets qualified institutional buyer thresholds.
Credentials are revocable if circumstances change, such as sanctions list
additions, and have expiration dates requiring periodic renewal, like annual
accreditation refresh requirements.
The Identity Registry maintains the authoritative list of verified investors.
Only registered, verified identities can hold compliant assets; unknown wallet
addresses are rejected before a transfer can succeed. This architecture keeps
identity checks in the transfer path without publishing investor identity files
on-chain. Claims and proofs needed for token eligibility are available to the
contracts, while detailed personally identifiable information remains with the
trusted verifier or the deployment's off-chain systems.
DALP uses the OnchainID protocol for decentralized identity credentials. See [Identity & Compliance
Architecture](/docs/compliance-security/security/identity-compliance) for technical implementation details on claim
structures, verification flows, and privacy-preserving designs.
### Jurisdictional rule templates standardize rule configuration [#jurisdictional-rule-templates-standardize-rule-configuration]
Different jurisdictions have fundamentally different rules that you can't
ignore. US Regulation D requires accredited investors for private placements
with specific income and net worth thresholds. EU MiFID II has its own investor
classification schemes that don't map cleanly to US definitions. Singapore MAS
imposes fit-and-proper requirements under distinct regulatory frameworks. When
regulations change, platforms need a controlled way to update the policies they
apply to tokenized assets.
DALP's Compliance Engine represents jurisdictional requirements as configurable
rule modules that compliance officers activate for specific assets. The Rule
Library provides jurisdictional templates as reusable starting points for common
controls, while the editable live unit is the per-token or per-asset module
parameters applied to an asset.
Use templates to prepare the policy pattern. Use asset module parameters to make
that policy active for an issued asset. That split matters during reviews:
changing a reusable template prepares the next configuration, but it does not
silently change policy on assets that already run on-chain.
| Compliance need | DALP control surface | Review check |
| ----------------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Eligible holder population | Identity claims, trusted issuers, country allow lists or block lists, and investor-count limits | Confirm the trusted issuer and country rules before the asset accepts transfers. |
| Primary issuance control | Supply, holder, capital-raise, and concentration modules selected on the asset | Confirm the module parameters match the approved programme limits before minting or distribution. |
| Reserve or collateral control | Collateral topic, trusted collateral issuer, claim amount, expiry, and configured collateral ratio | Confirm the off-chain reserve evidence before updating claims or relying on collateral statistics. |
| Transfer timing and venue | Lock-up, vesting, approval, transfer-restriction, and venue-related modules when the deployment uses them | Confirm the live module parameters before allowing secondary-market or venue-specific transfers. |
Configurable compliance modules can enforce geographic restrictions, investor
limits, transfer restrictions, holding periods, trading venue restrictions, and
collateral requirements. Treat rule changes for live assets as governed
operational changes: review the affected assets, explicitly re-apply or adjust
the asset's module parameters, and verify the affected path before relying on
the updated controls. For transfer controls, validate transfer behavior. For
collateral and issuance controls, validate the mint or issuance path as well.
### Audit evidence starts with the transaction record [#audit-evidence-starts-with-the-transaction-record]
DALP gives compliance and audit reviewers evidence from the transaction path,
not a separate after-the-fact spreadsheet. Standard token transfers run identity
and compliance checks before balances change. If a recipient identity check or
configured compliance module rejects the movement, the EVM transaction reverts
and token balances stay unchanged.
Use DALP evidence as the technical record for the platform action. Reviewers can
look at the submitted transaction, receipt status, indexed token events, holder
balances, configured compliance modules, trusted issuers, identity claims, and
related operational history for the asset. The [compliance transfer flow](/docs/architects/flows/compliance-transfer)
shows where the check happens. The [signing flow](/docs/architects/flows/signing-flow)
shows how DALP records the network transaction hash and waits for the matching
receipt before treating the operation as complete.
The institution still owns the examination file around that technical record.
It decides which policy the rule implements, whether the attempted action was
authorised under its programme, how long evidence is retained, and which
identity-provider, SIEM, custody-provider, or case-management records complete
the regulator-facing timeline. DALP supplies the platform evidence; the operating
model turns that evidence into an audit response.
## Identity verification and KYC/AML integration [#identity-verification-and-kycaml-integration]
### How investor onboarding works [#how-investor-onboarding-works]
DALP integrates with professional KYC/AML providers who specialize in identity
verification, sanctions screening, politically exposed person (PEP) checks, and
adverse media monitoring. You're not building verification infrastructure from
scratch or trusting unverified self-attestations that regulators reject. The
platform routes verification to specialists with established regulatory
relationships and proven track records.
Investors visit your white-labeled onboarding portal branded to your
organization and provide personal information along with required documentation
like passports and proof of address. The platform routes verification requests
to integrated KYC providers who perform identity verification, sanctions checks,
and PEP screening with results returning to your platform including risk scoring
and attestations. Your compliance officer reviews results and either approves or
rejects the application based on your risk policies. Approved investors receive
identity claims added to their OnchainID and their wallet address gets
registered in the Identity Registry, granting them access to interact with
compliant assets.
### Wallet binding prevents post-onboarding address substitution [#wallet-binding-prevents-post-onboarding-address-substitution]
That registration is the wallet-binding control. A verified investor cannot
receive or transfer compliant tokens by substituting an unverified wallet address
in an application field after onboarding. Token transfers check the Identity
Registry and the active compliance modules before balances move, so an unknown
or unregistered address fails the transfer path instead of becoming a new holder.
If an investor loses access to a registered wallet, an identity manager uses the
identity recovery flow rather than editing the registered address in place. The
flow is scoped to the operator's active organization, verifies that the target
wallet belongs to the participant being recovered, and requires the recovery
permission before execution. User-session execution also requires administrator
wallet verification; API-key execution authenticates through the API key session
instead. The workflow creates replacement wallets and a new OnchainID, marks the
previous wallet as lost, and attempts token recovery for recoverable affected
wallet balances. KYC claims do not migrate automatically to the new identity.
Trusted issuers or configured compliance providers must issue fresh claims before
the replacement wallet can satisfy the same eligibility rules.
DALP does not treat wallet replacement as a silent self-service address change.
Any deployment that requires dual authorization, a cooling-off period, or fresh
sanctions and AML screening before a replacement takes effect should enforce
those steps in its operational approval and issuer/provider workflow before
running recovery or reissuing claims.
For institutional investors, the process extends to corporate KYC/KYB
verification including beneficial ownership verification, entity structure
documentation, authorized signer verification, and institutional due diligence
questionnaires. The framework handles both individual and institutional
onboarding through the same architectural pattern with different verification
requirements.
### Ongoing monitoring maintains claim accuracy [#ongoing-monitoring-maintains-claim-accuracy]
Identity verification isn't one-and-done because investor circumstances change
over time. DALP supports periodic reverification requirements, continuous
monitoring for adverse events like sanctions list additions, and claim
expiration requiring renewal to ensure credentials remain current. If a KYC
provider flags an investor due to sanctions list addition or criminal
proceedings, their claims get revoked automatically and immediately.
Revoked claims don't confiscate tokens or seize assets. Investors retain
ownership of their holdings. However, they cannot transfer tokens until the
compliance issue is resolved and their identity is re-verified. This is exactly
how regulated securities should behave when investor eligibility changes.
Accreditation claims have expiration dates because a verified accredited
investor from 2022 might not qualify in 2025 due to changed financial
circumstances. The platform enforces claim freshness requirements and prompts
reverification when credentials near expiration, preventing expired credentials
from enabling improper transfers.
### Privacy and data protection balance transparency with protection [#privacy-and-data-protection-balance-transparency-with-protection]
Privacy regulations constrain how identity information is handled, while
regulated assets still need identity and eligibility checks. DALP separates
on-chain eligibility claims from off-chain identity documents so token contracts
can verify required claims without exposing the underlying personal data on a
public ledger. Detailed identity documents stay in the deployment's identity or
verification systems, protected by the access controls and retention policies
that the operator configures.
On-chain transaction history remains part of the ledger. Off-chain personal data
can be managed through the deployment's data-retention, access-control, and
data-residency processes. Legal teams should map those controls to the privacy
obligations that apply to the asset programme and jurisdiction.
## Security architecture and threat mitigation [#security-architecture-and-threat-mitigation]
### Multi-signature governance eliminates single points of failure [#multi-signature-governance-eliminates-single-points-of-failure]
DALP assumes individual credentials will eventually be compromised through
phishing, social engineering, device theft, or insider threats. Security is
layered so that no single person can cause catastrophic loss even if their
credentials are fully compromised. Multi-signature treasury controls require
M-of-N approval for sensitive operations, ensuring multiple independent parties
must coordinate for any high-risk action.
Sensitive operations should be routed through the approval policy configured for
that deployment, such as maker-checker review, M-of-N approval, transaction
limits, or custody-provider policy approval. The control objective is the same
across minting, burning, large transfers, emergency pauses, and contract
upgrades: one compromised account should not be able to inflate supply, destroy
value, halt trading, or deploy unsafe contract logic on its own.
Role-based access control separates platform access, system roles, asset roles,
and system module permissions. The model lets operators give each team only the
rights it needs: administrators manage organisation access, identity managers
maintain identity records and recovery, compliance managers configure policy
controls, token managers deploy assets, and auditors inspect operational and
security-sensitive surfaces without operator rights. For the full role model,
see [Authorization](/docs/compliance-security/security/authorization).
### Institutional custody controls protect high-value keys [#institutional-custody-controls-protect-high-value-keys]
Private keys controlling substantial value require protection meeting the same
standards banks apply to cryptographic material. DALP supports custody-aware
signing routes that delegate transaction signing and broadcasting to configured
providers instead of concentrating control in a single application hot wallet.
Fireblocks and DFNS integrations can handle provider-native signing,
broadcasting, nonce management, and approval polling. When a provider policy
requires approval, DALP keeps the transaction in its tracked workflow while the
provider-side approval completes or is rejected. DFNS approval callbacks are
accepted on a webhook endpoint only after HMAC signature verification; invalid,
malformed, or oversized callback payloads are acknowledged or rejected without
being dispatched into the approval workflow.
Custody integrations help address the primary digital asset risk, private key
theft or loss, by keeping signing inside provider-managed controls and approval
policies. This addresses the single biggest objection risk committees raise when
evaluating blockchain platforms: "How do we protect the keys?"
See [Security Architecture](/docs/compliance-security/security) for the broader security model, authentication
controls, and compliance architecture.
### Network security and monitoring detect attacks before damage occurs [#network-security-and-monitoring-detect-attacks-before-damage-occurs]
Production security hardening includes TLS encryption for all API communications
using modern cipher suites that prevent man-in-the-middle attacks. Default API
authentication uses session and scoped API-key controls; deployments that install
OAuth 2.0/OIDC plugins can add enterprise identity federation, but those plugins
are not active by default. Rate limiting prevents abuse and denial-of-service
attacks by throttling suspicious traffic patterns. IP allowlisting restricts
administrative operations to known networks, preventing remote attacks even with
stolen credentials. DDoS protection through Cloudflare or equivalent edge
networks absorbs attack traffic before it reaches your infrastructure. Web
application firewalls protect against common vulnerabilities like SQL injection
and cross-site scripting. Secrets management via HashiCorp Vault or cloud
provider secret stores prevents credentials from appearing in code or
configuration files.
DALP gives operators product evidence for incident investigation. Global
administrator routes emit structured audit events for successful and denied
administrator calls, including the user ID, route, timestamp, outcome, and
denial reason. Session-security routes let an authorised security operator
delete one browser session or all sessions for a user. Asset pause controls let
an operator with the asset Emergency role submit a wallet-verified pause
transaction that pauses token transfers for that asset.
Deployment monitoring, SIEM routing, on-call coverage, tabletop exercises, and
formal incident-history disclosures are operator controls. They depend on the
hosting model, contracted SLA, monitoring stack, and the operator's own incident
register. DALP can supply the platform control points and event evidence for an
investigation, but it does not turn the public product documentation into a
universal incident register for every deployment.
### Cybersecurity incident evidence boundaries [#cybersecurity-incident-evidence-boundaries]
Security questionnaires often ask whether the tokenization platform has had
unauthorised smart-contract interactions, erroneous minting or burning, signing
key compromise, registry tampering, long platform outages, or regulatory
notifications. Answer those questions from the deployment evidence pack, not from
a generic product claim.
| Incident question | DALP evidence to review | Product boundary |
| -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Unauthorised administrator access | Global administrator audit events for allowed and denied calls, plus account-session records | Audit events show platform route outcomes. The deployment's SIEM and identity provider show the full security timeline. |
| Compromised browser session | Remaining DALP session state after revocation, affected-user account records, and identity-provider or access logs | DALP deletes the targeted browser session rows. External identity-provider sessions and forensic logs remain under the operator's identity stack. |
| Erroneous or fraudulent minting, burning, or transfer activity | Token event history, transaction queue records, asset role assignments, pause-state changes, and related [token documents](/docs/developers/api-integration/token-documents) such as reserve audits, attestation reports, certificates, or custody-chain evidence | DALP records the requested and indexed asset activity plus the asset document metadata and file hash for uploaded token documents. The operator must classify whether the activity was authorised under its policy and whether off-chain evidence supports the asset state. |
| Signing key or claim-signer compromise | Custody-provider logs, DALP signer configuration, claim-signer key-rotation evidence, and issuer identity state | DALP supports rotation paths and custody-aware signing routes. Custody compromise analysis depends on the selected signer backend. |
| Registry tampering or identity abuse | Trusted issuer, claim, identity, and role-change records for the affected asset or participant | DALP exposes the identity and claim state needed for review. Legal impact and notification duties stay with the operator. |
| Availability incident over the disclosure threshold | Deployment monitoring, uptime records, transaction queue depth, restore drill records, and measured RTO/RPO evidence | Availability and incident-response commitments follow the selected deployment architecture, tested recovery plan, provider contracts, and SLA. |
For reserve-backed, certificate-backed, or physical-asset-backed programmes, add
asset-level document evidence to the review packet. [Token document records](/docs/developers/api-integration/token-documents)
can carry the file type, visibility, version group, upload timestamp, uploader,
and file hash for documents such as reserve audits, attestation reports,
certificates, storage receipts, and chain-of-custody files. DALP records those
document references; the issuer, custodian, trustee, auditor, or warehouse
operator still proves the off-chain reserve or asset record.
Use this split when preparing auditor or procurement evidence. Public DALP docs
describe platform controls and document records. The deployment evidence pack
discloses the actual incident history, investigation timeline, customer
notifications, measured recovery results, and regulatory correspondence for the
environment under review.
### Operational security and recovery procedures handle inevitable failures [#operational-security-and-recovery-procedures-handle-inevitable-failures]
Production incidents need product controls and operator procedures. DALP covers
the product-side controls: session revocation, role-gated asset pauses,
custody-aware signing routes, claim-signer key rotation, global administrator
audit events, and high-availability deployment patterns. The operator owns the
incident commander, notification process, regulatory disclosure decision, and
evidence retention policy for the environment.
For key compromise, contain the affected signing path before resuming normal
activity. Depending on the key type, that can mean pausing affected assets,
revoking user sessions, rotating a provider claim signer, or changing custody
policy with the selected signer backend. Keep the incident timeline tied to the
available audit events, transaction records, custody logs, and identity-provider
logs used to make each decision.
System failure recovery depends on the deployment architecture selected for the
environment. For production deployments, review the high-availability design,
backup coverage, restore drills, recovery time objectives (RTO), recovery point
objectives (RPO), and queue-recovery evidence that apply to that environment.
Bank and security reviewers should ask for measured evidence, not a universal
product promise. A complete evidence pack identifies the selected pattern,
PostgreSQL and cache recovery plan, object storage backup and restore path, RPC
or node failover plan, alert ownership, last restore drill, achieved recovery
runtime, and any accepted gap against the target RTO or RPO.
DALP's self-hosting architecture guidance gives operators patterns for
availability and recovery, but the actual outage record and recovery evidence
come from the deployed platform. Use [deployment topology](/docs/architects/overview/deployment-topology),
[high availability](/docs/architects/self-hosting/high-availability), and
[backup and recovery](/docs/architects/self-hosting/high-availability/backup-recovery)
to connect review questions to the right operating evidence.
When a bank reviewer asks for HA or DR proof, separate the design from the
measured evidence:
| Review question | Evidence to ask for |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Which runtime surfaces must recover? | Deployment topology showing ingress, API services, workers, indexers, the Chain Gateway, PostgreSQL, workflow engine state, object storage, observability, custody, and EVM RPC or node access. |
| What data loss is acceptable? | The deployment RPO, the backup or point-in-time recovery source used in drills, and the restored database or workflow journal point. |
| How fast can service return? | The deployment RTO, the restore runbook, the measured drill duration, and the route-switch or traffic-restoration step. |
| What remains externally governed? | Custody-provider recovery, signer availability, RPC or node provider recovery, incident commander ownership, and any provider escalation records. |
| How is restored state trusted? | Application health checks, indexer catch-up, queue recovery, and reconciliation between database state, indexed state, and chain state. |
For a review packet, start with [Deployment topology](/docs/architects/overview/deployment-topology)
to map failure domains, then use [Backup and recovery](/docs/architects/self-hosting/high-availability/backup-recovery)
to plan restore evidence. Do not treat a target RTO or RPO as proof until a
restore drill has measured it in the environment being reviewed.
Smart contract upgrade procedures should be reviewed from the deployed contract
architecture, governance policy, signer policy, test evidence, and change log.
For upgradeable deployments, evidence should show who approved the change, which
contract version was deployed, what pre-production validation ran, and how the
operator would contain or roll back an unsafe change.
## Standards, certifications, and regulatory alignment [#standards-certifications-and-regulatory-alignment]
### Industry standards provide interoperability and best practices [#industry-standards-provide-interoperability-and-best-practices]
DALP implements standards that enable interoperability with existing financial
infrastructure and demonstrate alignment with industry best practices. The
platform implements ERC-3643 for permissioned token transfers with embedded
compliance and uses FIDO2/WebAuthn as an active strong-authentication standard
that eliminates password vulnerabilities. OpenID Connect identity federation
and OAuth 2.0 authorization for secure API access are available through
installable authentication plugins and are not active by default in every
deployment.
These aren't checkbox features. They are architectural choices that determine how
the platform integrates with broader financial infrastructure and whether
institutions can adopt it within existing operational frameworks.
### Regulatory framework alignment supports global deployment [#regulatory-framework-alignment-supports-global-deployment]
DALP provides configurable controls that regulated asset programmes can map to
their jurisdiction-specific obligations. Compliance teams can configure identity
requirements, transfer restrictions, investor limits, holding rules, and audit
records for each asset programme. The same architecture can support different
regulatory contexts, but the legal interpretation and final control design stay
with the operator and its counsel.
DALP does not make a deployment automatically compliant. It gives operators the
technical control points and evidence trails they need to implement, test, and
review their compliance model for the relevant jurisdiction.
### Security certifications demonstrate operational maturity [#security-certifications-demonstrate-operational-maturity]
Organizations deploying DALP typically pursue certifications that demonstrate
operational maturity to regulators, auditors, and institutional customers. SOC 2
Type II attestation covers service organization controls for security,
availability, and confidentiality through independent audit. ISO 27001
information security management system certification demonstrates systematic
security practices. Smart contract audits provide third-party security review of
contract code by specialized blockchain security firms. Penetration testing
through regular external security assessments identifies vulnerabilities before
attackers exploit them. Regulatory examinations through cooperation with
securities regulators reviewing operations validate that compliance claims match
operational reality.
These aren't automatic with the platform. They are organizational certifications
your deployment pursues with DALP's architecture supporting the requirements
rather than fighting against them.
## What this means for adoption [#what-this-means-for-adoption]
Risk committees approve platforms that demonstrate control through evidence, not
promises. DALP provides audit trails for eligibility checks, identity
verification, and rule evaluation. Security controls with multi-signature
operations and custody-aware signing routes reduce single-key risk. Configurable
rule modules help teams align asset controls with their legal and operating
model. Privacy-aware identity design keeps personal data off-chain while still
letting token contracts verify required claims.
When you present DALP to your risk committee, you're presenting a platform
built for regulated financial instruments with institutional control points, not
a developer experiment retrofitted with compliance features after launch. Use
DALP's audit trails, transaction records, health surfaces, and deployment
evidence pack to show what the platform enforced, who acted, and how the
environment was operated.
Compliance controls are part of transaction execution. Security is built into
the operating model. Privacy starts with clear separation between on-chain claims
and off-chain identity records.
## Where to next [#where-to-next]
* **[DALP overview](/docs/business/dalp-overview)** – Platform features
and capabilities across the asset lifecycle
* **[Architecture](/docs/architects/overview)** – Technical details
on system design and component interactions
* **[High availability](/docs/architects/self-hosting/high-availability)** –
Recovery patterns, RTO/RPO planning, and evidence expectations for
self-hosted deployments
* **[Backup and recovery](/docs/architects/self-hosting/high-availability/backup-recovery)** –
Restore testing and recovery evidence for HA/DR reviews
* **[Glossary](/docs/business/glossary)** – Key terms and definitions
for compliance and security concepts