Start with where protected authority belongs and what must keep working, then choose infrastructure around those answers.
A deployment decision should reflect the customer's sites, security boundaries, protected data, devices, network conditions, continuity expectations, enterprise systems, support model, and regulatory requirements—not a generic preference for cloud or on-premises.
Resolve these decisions before treating a deployment model as final.
The answers establish who owns what, where data moves, and what must be validated before production use.
Where should protected operational authority live?
Determine where identity verification, authorized searches, watchlists, cases, evidence, reporting, users, local audit, and regulated credentials should operate for the customer's security and continuity requirements.
Which information may leave the operational boundary?
Define business, licensing, release, support, and privacy-minimized health information separately from patron identity, case evidence, source credentials, and operational PII.
What must continue during disruption?
Identify critical checkpoints and decide how connectivity loss, upstream-source outages, local hardware problems, and commercial-control interruptions should behave.
Which devices and local systems participate?
Inventory mobile capture, dedicated scanners, local hardware, directories, security systems, notifications, reporting destinations, and other required integrations.
How will providers be selected?
Evaluate providers against security, availability, geography, legal or regulatory fit, retention, support, cost, and operational requirements behind explicit integration contracts.
What proves the deployment is ready?
Validate roles, sources, site and device topology, data lifecycle, backup and recovery, credentials, release policy, legal notices, acceptance scenarios, support ownership, training, and production readiness.
IDSENTRA