Begin With the Data and the Use Case
Mobile reporting can help personnel capture notes, photographs, recordings, and draft narratives closer to the event. It also moves sensitive work onto devices that can be lost, shared, taken off-network, connected through untrusted networks, or used alongside personal applications. A secure rollout therefore begins with two questions: what information will the device access, process, transmit, or store, and which operational conditions must the workflow support?
This checklist is a planning aid, not a compliance determination or legal opinion. Criminal Justice Information Services requirements can depend on the data, architecture, access path, agency agreements, and applicable state implementation. Agencies should confirm their interpretation with their CJIS Systems Officer, state CJIS Systems Agency, security personnel, counsel, records staff, and other responsible officials.
1. Define Ownership and Deployment
Is the workflow limited to agency-issued devices, or does it include personally owned devices? Who owns the phone number, account, device backup, and application data? Can the agency configure and monitor the full device, only a managed work profile, or only the application? What happens when a device is reassigned, an employee separates, or a personal device leaves the program?
NIST Special Publication 800-124 Revision 2 covers both organization-provided and personally owned mobile deployments. It recommends treating security as a lifecycle that includes understanding the use case, assessing risk, selecting a deployment and management model, setting policy and configuration, testing, auditing use, and securely disposing of or reusing devices. BYOD may provide flexibility, but it also introduces different security, support, records, and employee-privacy considerations that should be resolved before deployment.
2. Verify Identity and Control Access
Does the device require an approved local authenticator before use? Does the reporting application authenticate the individual user rather than relying only on an unlocked phone? Are permissions based on role and case need? Can access be removed promptly without waiting to recover the physical device? Are privileged administrative functions separated from normal field use?
FBI CJIS Security Policy version 6.0 says that an authorized mobile device used to access Criminal Justice Information must use local device authentication. It also recognizes that limited-feature mobile operating systems generally do not support multiple user accounts, requiring access control to be implemented by the application accessing CJI. The policy separately addresses advanced authentication and narrowly defined, CJIS Systems Officer-approved compensating controls. Agencies should evaluate these provisions in the context of their actual access architecture rather than assuming a phone's standard screen lock is the complete control.
3. Limit and Protect Local Data
What information must remain on the device when it is offline? Is CJI encrypted when resident on the device? Do cached files, previews, credentials, and temporary exports disappear when the session ends or when policy requires? Can a photograph or recording enter the personal camera roll, consumer cloud backup, clipboard, messaging app, or another unmanaged location? Can the agency remotely revoke application access or remove managed data?
CJIS Policy version 6.0 includes mobile risk mitigations covering encryption of CJI resident on a device and removal of cached information, including authenticators, when a session ends. The safest implementation depends on the workflow, but the design principle is consistent: retain no more local data than operations require, know every location where data can persist, and make deletion and revocation testable rather than assumed.
4. Manage Configuration, Applications, and Updates
Is every authorized device inventoried? Can administrators enforce minimum operating-system and application versions? Are rooted, jailbroken, unsupported, or materially out-of-policy devices blocked? Is there a documented application approval process? Can the agency identify devices that have stopped checking in, missed a critical update, or disabled a required control?
CJIS Policy says agencies should monitor mobile devices to keep their patch and update state current and have a process to approve software used on smartphones and tablets that access CJI. It notes that meeting some system-integrity requirements may require mobile device management, an application, or supporting service infrastructure. NIST likewise describes centralized device management and endpoint protection as part of a broader mobile security program. Buying an MDM product alone is not the outcome; the agency must define, enforce, monitor, and periodically test its configuration.
5. Plan for Networks and Interrupted Connectivity
Does the application protect data over cellular, agency Wi-Fi, and other permitted networks? What occurs when connectivity drops midway through a capture or upload? Does the user see whether information is saved locally, queued, synchronized, rejected, or duplicated? Can a partially uploaded record be mistaken for a complete submission? Are server certificates and trust decisions handled by the managed application rather than left to user judgment?
Offline capability should be designed as a controlled state, not an exception nobody can inspect. Agencies can test interruptions during authentication, capture, upload, editing, approval, and logout. The resulting state should be clear to the user and recoverable without creating untracked copies or silently losing material.
6. Prepare for Loss and Compromise
Who does an officer contact after a device is lost, stolen, left unlocked, or suspected of compromise? What information should the officer provide? Who disables accounts, revokes tokens, assesses exposed data, preserves necessary logs, and decides whether additional notifications are required? Can the agency act after hours, and has that process been exercised?
CJIS Policy section 5.20.5 calls for additional or enhanced incident reporting and handling procedures for mobile scenarios. It identifies loss of device control, total device loss, device compromise, and loss or compromise outside the United States as situations requiring special reporting procedures. A one-page field instruction, backed by a staffed response path, is more useful than a lengthy plan personnel cannot locate during an incident.
7. Preserve Accountability in the Reporting Workflow
Can the system distinguish captured source material, machine-generated draft text, officer edits, supervisor changes, and the final approved report? Are actions associated with individual accounts and reliable timestamps? Can authorized reviewers determine what was submitted, what changed, and which version entered the records system? Security includes the integrity and reviewability of the work product, not only encryption of the device.
8. Test Departure, Reassignment, and Disposal
Before launch, simulate an employee transfer, a lost phone, a replacement device, a failed remote wipe, an expired credential, and device disposal. NIST's lifecycle guidance includes both disposal and reuse because sensitive remnants, lingering access, and unmanaged backups can survive normal administrative transitions. The agency should be able to show that access was revoked and managed data was handled according to policy.
A secure mobile reporting program is a combination of device controls, application controls, operating procedures, and human behavior. The most useful procurement question is not whether a product has a security label. It is whether the agency can map the complete data path, assign responsibility at every stage, test important failure cases, and produce evidence that the chosen controls operate as intended.
