Authentication and access control
Most breaches of court systems begin with a credential, not an exploit.
EmpanelJMS is built on the assumption that account compromise is the likeliest path in, and that the answer is to limit what any single account can reach.
Multi-factor authentication
MFA is enforced for administrative, privileged, and remote access. Court staff working from a courthouse network and an administrator connecting remotely are not treated as equivalent risks, and the platform's authentication requirements reflect that.
Verification codes are delivered by text message or email, and the delivery method is set per user by a court administrator. Codes are single-use, expire after a short window, and are rate-limited. EmpanelJMS never stores a verification code — only a hash of it — so a code cannot be recovered from the database or from a log.
Where a court uses single sign-on, multi-factor authentication is applied by the court's own identity provider under the court's own policy, rather than being duplicated by EmpanelJMS.
Single sign-on and identity integration
Courts that operate their own identity infrastructure should not have to maintain a second, parallel set of accounts for jury management. SSO integration lets court IT provision, review, and revoke access through the directory they already control. When a staff member leaves, disabling their account in the court's identity system removes their access to EmpanelJMS — there is no orphaned local account to remember.
What ships today. EmpanelJMS supports OpenID Connect (OIDC) with the authorization code flow and PKCE. It works with any standards-compliant OIDC provider, including Microsoft Entra ID. Active Directory Federation Services speaks OIDC in current versions and is supported on that basis. Courts standardized on SAML 2.0 should raise it during evaluation so we can confirm the integration path before anything is committed.
Configured per court. Single sign-on is enabled and configured for each jurisdiction independently. A court that uses SSO and a court that does not can run on the same installation, each pointed at its own identity provider. Nothing changes for a court that chooses not to enable it.
Users are matched on an immutable directory identifier, not on an email address. A staff member who marries, changes their name, or moves to a new email domain keeps their EmpanelJMS access without administrator intervention, and an address later reassigned to a different employee cannot inherit the previous holder's access.
Accounts are never created automatically from a directory sign-in. A user must already exist in EmpanelJMS and be explicitly linked to a directory account before single sign-on will admit them. Authenticating successfully with the court's identity provider is not, by itself, authorization to open juror records.
Local accounts remain available where a court wants them. Each account is individually set to single sign-on only, local password only, or either. Courts commonly place their own staff on SSO-only so that directory offboarding is authoritative, while retaining a small number of local accounts for support access and for the case where the identity provider itself is unavailable. A court that prefers no local sign-in at all can disable it entirely.
Sign-in attempts are recorded whether they succeed or fail, including attempts by directory accounts that are not linked to an EmpanelJMS user.
Removing access when someone leaves
This is worth describing precisely, because vendors often describe it loosely.
Where a court has placed a staff member on single sign-on only, disabling that person's account in the court's directory stops them signing in to EmpanelJMS. There is no second password to remember to revoke, and no orphaned local login left behind — which is the failure mode that shows up in audits, particularly in a county running dozens of applications.
EmpanelJMS does not currently synchronise account status from the directory automatically. The EmpanelJMS account itself remains present until an administrator disables it, and an already-established session continues until it expires. For most courts this distinction is immaterial, because the person cannot sign in again. Where a court needs immediate termination of active sessions, that should be raised during implementation so the process is agreed rather than assumed.
Role-based access control
Permissions in EmpanelJMS follow the roles that already exist in a jury office. A clerk processing qualification questionnaires does not need access to payment disbursement. A financial officer approving juror payments does not need to see questionnaire responses. Granular, role-based permissions mean staff see what their work requires and no more, which limits the blast radius of any single compromised account.
Isolated court instances
Each court's data is logically separated. One jurisdiction's juror records are never mingled with another's, and there is no query path by which a user in one court can reach data belonging to another. For courts evaluating multi-tenant software, this is usually the first question asked, and it should be.
Encryption and data protection
Juror data is encrypted in transit and at rest. Data moving between a juror's browser, the court's staff interface, and the application is protected on the wire; data at rest in the database and in backups is protected in storage. The intent is that a copy of the data obtained without authorization — whether from a network capture or a storage medium — is not readable.
Payment and financial data
Juror payment and disbursement involve financial details that carry their own handling requirements. EmpanelJMS treats payment data as a distinct category with access restricted to the roles that administer it.
Audit logging and accountability
In a jury system, the question is rarely only whether data was protected. It is who did what, and whether the record of it can be produced. Panel selection, juror excusals, deferrals, and payment approvals are all actions that may later need to be explained — to a presiding judge, to counsel raising a challenge, or to an auditor.
EmpanelJMS maintains an audit trail of user activity tied to individual accounts. Because access is role-based and authenticated per user rather than shared, actions attribute to a person rather than to a generic office login. This matters more in jury administration than in most software: a defensible panel depends on being able to demonstrate how it was drawn.
What is recorded. Sign-in activity is logged whether the attempt succeeds or fails, including the account used, the time, the originating address, and the device or browser reported. Failed attempts record the reason — wrong password, disabled account, or a directory identity not linked to an EmpanelJMS user — so a pattern of attempts against a single account is visible rather than buried.
Administrative changes to user accounts are recorded separately from the actions those users take, so a permission change and the work done under it are distinguishable after the fact. Outbound messages to jurors are logged with their delivery outcome, which matters when a juror states they were never notified.
Consent and communication preferences carry their own append-only record. Where a juror or staff member agrees to receive text messages, the log retains the exact wording shown to them, the version of that wording, the time, and the address it was given from — and the same for a later opt-out. That record is not editable through the application.
Backup, disaster recovery, and continuity
A jury system that is unavailable on a Monday morning is not an inconvenience; it is a courtroom that cannot seat a panel.
Continuity planning for jury management has to account for the fact that jury operations run on a fixed calendar set by the court, not by the vendor.
Backups
EmpanelJMS deployments are backed up on a defined schedule, and backup integrity is verified rather than assumed. A backup job that reports success while producing nothing is a failure mode we design against explicitly.
Disaster recovery
Cloud deployments run on Microsoft Azure and Amazon Web Services in U.S. regions, configured for disaster-recovery readiness. On-premises deployments are installed with recovery procedures documented for the court's own IT staff, since in that model the court controls the hardware and the recovery path runs through their operations.
Business continuity
Jury operations follow the court's term calendar. Summons go out on a schedule set by statute and local rule, and a service interruption during a summons cycle has consequences that a later interruption does not. Continuity planning for EmpanelJMS accounts for the operational rhythm of a jury office rather than treating all downtime as equivalent.
Why a separate jury system is itself a continuity measure
When a court is hit by a cyber incident, reporting tends to focus on case management and electronic filing. Jury operations are rarely mentioned, and they have a characteristic that most court functions do not: a hard external deadline involving hundreds of members of the public who have already rearranged their lives around a reporting date.
If a case management system is unavailable on a Monday morning, hearings are continued and counsel are notified. It is disruptive and it is recoverable. If the jury system is unavailable that same morning, nobody can tell the panel whether to report. The summonses went out weeks ago and cannot be quietly rescheduled.
EmpanelJMS runs as a distinct system with its own database, on infrastructure separate from the court's case management environment. A court-wide incident that takes down case management does not, by itself, take down jury operations — and the reverse is equally true.
This is not a claim of high availability, and it should not be read as one. It is a statement about architecture: systems that fail together are systems that share a dependency. The value of separation shows up in the accounts courts give of their own incidents. Describing a 2023 ransomware attack that wiped his circuit's case management system, Chief Judge John Miller of Florida's First Judicial Circuit noted that the county clerks' systems operated independently and stayed online, which is what allowed judges and staff to keep working from basic docket information. His account is reported here.
Courts evaluating any jury system should ask a question that is easy to defer and expensive to answer late: if the jury system is unavailable on a Sunday evening, what does a summoned juror hear when they call the reporting line, and who decides whether Monday's panel is cancelled?
Where EmpanelJMS runs
Cloud deployments of EmpanelJMS run on Microsoft Azure and Amazon Web Services, in United States regions, with workloads divided between them by function. We name our providers rather than describing them generically, because a court's IT department should be able to evaluate the infrastructure their juror data sits on and should not have to ask twice.
What our providers are responsible for, and what we are
Microsoft and Amazon each maintain broad compliance authorizations for their infrastructure, including FedRAMP, SOC 2, and ISO 27001. It is important to be precise about what that means: those authorizations cover the infrastructure layer, not EmpanelJMS. Under the shared responsibility model, the provider secures the physical datacenters, the hypervisor, and the network fabric. Everything above that line — the operating system, the database, the application, and the configuration of all three — is our responsibility. A vendor that presents its host's certifications as its own is telling you something misleading, and we would rather explain the division than blur it.
Because EmpanelJMS runs on virtual machines we operate rather than on fully managed services, operating system patching, database configuration, application hardening, backup, and access control all sit with us. Court IT reviewers are generally familiar with this distinction, and we state it so there is no assumption that our providers handle work that we do.
On-premises deployment
Where court policy or state law requires that records remain on equipment the court controls, EmpanelJMS installs on the court's own servers. This is a genuine deployment option, not a hosted product with an on-premises label — the same application runs in both models. In that arrangement the court holds the infrastructure responsibilities described above, and the division is documented in the engagement rather than left to assumption. For courts whose policies require that records stay on court-controlled equipment, this is the path that meets the requirement.
Tenant and data separation
Each court's data is logically separated from every other court's, and there is no query path by which a user in one jurisdiction can reach another jurisdiction's records.
Who owns the data
The court owns its data. Nothing in our engagement changes that.
EmpanelJMS is the system the court uses to administer its jury operations; the juror records, master wheel, questionnaire responses, and payment history belong to the court.
Data retention and disposal
Juror records are subject to the court's own retention schedule, which is set by statute, rule, or records policy rather than by a software vendor. EmpanelJMS is configured to support the retention rules the court operates under.
Data portability and exit
A court should be able to leave. The National Center for State Courts advises courts to build exit provisions into technology contracts so they can transition if a vendor no longer meets their needs, and we think that advice is correct. Courts running EmpanelJMS can obtain their data in a usable form, and we will not treat a court's own records as leverage to retain the account.
Vulnerability management and incident response
Keeping the platform patched
Software security is not a state that is reached once. Dependencies acquire known vulnerabilities over time, and a platform that was current at deployment is not current a year later without ongoing work. EmpanelJMS is maintained on an ongoing basis rather than shipped and left.
Responsible disclosure
We maintain a responsible-disclosure process so that security researchers and court IT staff can report issues to us directly and get a response. Read our disclosure policy →
Incident response
Integrated Jury Solutions maintains a written data breach response plan, built on NIST Special Publication 800-61 and the impact definitions in FIPS Publication 199. It is reviewed annually, and the review is recorded whether or not anything changed. A court's IT department may request a copy.
Incidents are classified by severity on a four-level scale, assessed against confidentiality, integrity, and availability, and against whether the effect is confined to one system or spans the environment. Classification drives the response: who is engaged, whether legal counsel and law enforcement are brought in, and how quickly affected courts are told.
For the most severe classification — an incident affecting multiple clients — impacted courts are notified within four hours. We state that figure rather than saying “promptly” because a court has its own breach-notification obligations under state law, and those clocks do not start until the vendor makes the call. Lower-severity incidents are notified on a timeline matched to their assessed impact, and the plan requires that determination be documented rather than assumed.
A suspected exposure of personally identifiable information is reportable on suspicion alone. It does not wait for confirmation. A suspected incident can later be closed by establishing that no PII was involved, but the reporting obligation is not deferred while that is being worked out. For a jury system, where the records are names, addresses, dates of birth, and in many jurisdictions answers about health and criminal history, that ordering matters.
Incident communications run over channels verified to be unaffected by the incident under investigation — a detail that sounds obvious until the compromised system is the mail server.
Every incident requires a root cause analysis, so that the remediation addresses the weakness rather than the symptom. Enterprise-level incidents additionally require a written follow-up report and a lessons-learned review covering what happened, how it was found, what was affected, whether the response worked, and what changes prevent a recurrence.
Because Integrated Jury Solutions is a small company, incident response is direct. There is no support tier to escalate through and no queue between a court and the person accountable for the platform. That is a genuine advantage in the first hour of an incident, and we would rather describe it plainly than imply a larger operation than we run.
Cyber liability insurance
Integrated Jury Solutions carries cyber liability insurance. We mention it because courts ask, and because a certificate of insurance is frequently required before a contract is executed — it is easier for everyone if the answer is known early rather than discovered during procurement.
Insurance is not a security control and we do not present it as one. It does not prevent an incident and it does not shorten a recovery. What it does is make a vendor's obligations after an incident meaningful rather than theoretical, which for a small vendor is a fair question for a court to ask. A current certificate is available to courts on request.
We describe our security program accurately. Where a formal certification is in progress rather than complete, we say so. Courts deserve a vendor that doesn’t overstate its posture, and we would rather answer a hard question plainly than have it surface during contracting.
Security questions courts ask
Where is our juror data stored?
In a cloud deployment, on Microsoft Azure and Amazon Web Services in United States regions, with workloads divided between them by function. In an on-premises deployment, on the court's own servers, under the court's physical and administrative control. Our providers hold compliance authorizations for their infrastructure; the operating system, database, and application layers are our responsibility under the shared responsibility model. Courts subject to policies requiring in-state or on-premises storage of records can meet those requirements with EmpanelJMS.
Can our IT department review your security posture before we buy?
Yes. We will walk your IT and security staff through the platform's architecture, answer security questionnaires, and discuss the specifics of your deployment model. Court IT should not be asked to approve software they have not been allowed to examine.
What happens to our data if we stop using EmpanelJMS?
The data is the court's, and the court can take it. We support obtaining your records in a usable form at the end of an engagement.
Who at Integrated Jury Solutions can see our juror data?
Access to court data by our staff is limited to what support and maintenance require, and is tied to identified individuals rather than shared accounts.
How do you handle security updates for on-premises installations?
On-premises courts control their own upgrade schedule, and we provide updates along with the information needed to apply them. The division of responsibility is set out in the engagement so there is no ambiguity about who applies what.