Permit and Licensing System Requirements Checklist

Define the public decision before designing the portal

A permit or license system may support building work, business activity, professional practice, events, land use, environmental activity, vehicles, facilities, food service, occupancy, or regulated equipment. These programs share workflow patterns but not authority, eligibility, evidence, inspection, fee, appeal, or records rules. Begin with the governing program and public outcome rather than a generic online form.

Map the journey from public guidance and pre-application help through account or assisted access, application, evidence and plan submission, completeness review, fee calculation, payment, technical review, consultation, inspection, correction, decision, issuance, conditions, public verification, amendment, renewal, enforcement referral, suspension, revocation, appeal, closure, retention, and disposition. Include abandoned drafts, duplicate applications, changed property or business ownership, unavailable reviewers, partial payments, revised plans, failed inspections, emergency work, expired approvals, and system outage near a statutory deadline.

Qualified program, legal, planning, engineering, safety, finance, records, privacy, accessibility, and language professionals must define jurisdiction-specific policy. Software should implement approved rules with effective dates and preserve accountable decisions. It must not infer legal authority from a product template or claim that digitizing a process makes the agency compliant.

Separate programs, applications, approvals, and credentials

Represent authority, jurisdiction, permit or license type, rule version, cycle, applicant, person, organization, representative, property, asset, project, application, requirement, answer, evidence item, plan set, review, comment, fee, payment, inspection, correction, decision, condition, issued credential, amendment, renewal, enforcement referral, appeal, communication, and record class separately. One project may need several approvals; one business may hold several licenses; one application may involve several parcels, owners, contractors, or responsible professionals.

Use stable identifiers and explicit relationships. A permit number should not double as a person's identity, payment reference, property key, and document folder. Preserve submitted snapshots so a later profile, address, plan, or policy change does not rewrite what reviewers considered.

Define states and transitions for each record. Draft, submitted, received, incomplete, under review, correction requested, consultation pending, inspection scheduled, approved, denied, issued, active, expired, suspended, revoked, appealed, superseded, and closed have different meanings. Show which actor owes the next step and which clock applies. Avoid a single “pending” label that causes applicants to call for status and managers to lose backlog visibility.

Translate policy into versioned requirements

For each eligibility, evidence, plan, fee, routing, review, inspection, notice, renewal, and enforcement rule, record the authoritative source, policy owner, scope, effective period, inputs, result, explanation, exception authority, and review schedule. Separate deterministic calculations from professional judgment. Software may calculate a fee using an approved schedule; it should not disguise a discretionary safety or planning judgment as an automatic score.

Version policy by submission, decision, or other approved trigger. If requirements change while an application is open, define whether the prior rules remain, transitional rules apply, or the applicant must satisfy the new version. Preserve the rule and inputs used for every consequential calculation.

Test boundary conditions: work exactly at a size threshold, an address crossing jurisdiction lines, mixed uses, several license classes, a renewal submitted at the deadline, a fee waiver, phased construction, changed ownership, an inspection after rule change, and a prior approval that may or may not remain valid. Make unresolved interpretations visible to the responsible official.

Make complex applications understandable and recoverable

Organize the application around the applicant's task, not the agency org chart. Explain eligibility, required preparation, estimated effort, fees and uncertainties, review steps, likely timelines, inspection needs, public-record implications, and help before requesting detailed information. Ask only questions supported by program need or approved reporting.

Support save and resume, meaningful sections, visible progress, clear validation, review before submission, confirmation, and safe correction. Preserve valid work after an error. State deadlines with timezone and define whether submission means button press, server receipt, completed payment, or validation. Handle files already uploading when the deadline arrives.

USWDS guidance for complex forms recommends progressive disclosure, small meaningful steps, save-and-resume support, mobile consideration, and blame-free error recovery. It is designed for U.S. federal experiences, not a universal legal requirement, but it provides valuable evidence for testing public workflows. Research wording and flow with representative applicants, including first-time users and people completing work under stress.

Support organizations, representatives, and assisted service

Applicants may act personally or for a company, client, property owner, household, association, contractor, or professional practice. Model representation with scope, evidence, start, expiration, revocation, and visibility. Do not assume the account email is the legal applicant or allow a former employee to retain permanent access to every organizational license.

Support agency staff, call centers, counters, inspectors, translators, community partners, and authorized representatives without falsifying who supplied information. A staff-entered paper application should identify the source, operator, date, and applicant confirmation required by policy. Provide phone, in-person, mail, or other routes where obligations and user needs require them, then bring those cases into the same controlled workflow.

Separate an organization's administrator from agency authority. Organizational administrators may invite colleagues or manage billing contacts but should not grant professional credentials, approve their own applications, or view restricted enforcement material. Define what happens when the last administrator leaves, an invitation reaches the wrong person, two accounts claim the same organization, or the agency must verify a transfer without taking control of the applicant's account.

Choose identity assurance based on transaction risk

Browsing requirements, checking status, applying, signing an attestation, paying, changing ownership, scheduling an inspection, and receiving a professional credential do not necessarily require the same identity confidence. Determine potential harm from impersonation or account compromise and select proportionate proofing, authentication, federation, recovery, and transaction confirmation.

NIST SP 800-63-4 provides a risk-based model for identity proofing, authentication, and federation in government systems and includes security, privacy, customer-experience, and redress considerations. Its normative requirements apply within defined U.S. federal contexts. Other organizations can use its reasoning without automatically claiming conformance.

Design duplicate-account resolution, contact changes, lost authenticators, delegated access, suspected fraud, deceased or dissolved owners, and organizational transfer. Strong enrollment paired with weak help-desk recovery is not strong identity. Avoid collecting identity documents or biometrics when the transaction does not justify them.

Manage plans, evidence, and revisions as controlled records

Define each required document or data set, acceptable alternatives, format, size, signer, validity period, review method, sensitivity, and retention. Preserve the original submission, version, checksum where useful, uploader, time, related requirement, review outcome, comments, and supersession. A folder named “final plans” is not a dependable revision history.

Scan or isolate untrusted files, validate formats, support resumable upload, and provide mobile-friendly alternatives. For large drawings or models, define transfer, rendering, annotations, supported versions, and archival format. Do not expose permanent public storage links.

Structure review comments by discipline, location or drawing reference, requirement, severity, owner, status, and response. Applicants should see exactly what needs correction without gaining access to protected internal notes. A revised plan set should state which comments it addresses; reviewers need comparison tools and a complete history rather than detached email threads.

Coordinate review without hiding responsibility

Define completeness screening, technical disciplines, consultations, assignment, workload, parallel or sequential work, service targets, escalation, conflicts, supervisor review, and decision authority. Preserve who reviewed which version, what they concluded, and why. Reassignment should not erase earlier work or make a new reviewer appear responsible for it.

Use queues that show age, deadline, blocked reason, applicant response, consultation, and workload. Measure active agency time separately from documented pauses where policy allows. Prevent staff from manipulating performance reporting by moving work into an undefined hold state.

Comments and approvals should have controlled vocabularies where consistency matters but allow accountable rationale. Require an approved override path. Do not let a dashboard color substitute for a professional conclusion or make several partial approvals appear as final issuance.

Calculate fees and reconcile payments defensibly

Model fee schedules, effective dates, units, minimums, deposits, exemptions, waivers, penalties, refunds, credits, adjustments, taxes where applicable, and authority. Show applicants an itemized calculation and whether an estimate can change after review. Preserve every calculation version and approved adjustment.

Keep invoice, payment intent, processor transaction, settlement, refund, chargeback, ledger posting, and application balance distinct. Use hosted payment methods that reduce sensitive payment-data exposure where suitable. Provider success does not prove agency reconciliation. Handle duplicate callbacks, abandoned checkout, delayed settlement, partial payment, overpayment, and processor outage idempotently.

Restrict manual adjustments and refunds by role, amount, reason, and dual approval where policy requires. Reconcile daily or at an approved frequency to finance records and expose unmatched transactions in an accountable queue. Reports should distinguish assessed, waived, invoiced, collected, settled, refunded, disputed, written off, and outstanding amounts so cash movement cannot be mistaken for earned revenue or completed permitting work.

Connect inspections to the approved scope

Represent inspection type, prerequisite, requested window, assignment, location, approved plans, checklist version, observations, media, result, correction, reinspection, and inspector certification. Scheduling should consider qualification, geography, access, duration, dependencies, and applicant communication without promising an exact time the operation cannot meet.

Inspectors need secure, accessible, low-bandwidth or offline access to the minimum necessary record. Queued changes must show synchronization state and conflicts. Device loss should not expose a permanent local archive. Location and photos require explicit purpose, access, retention, and metadata rules.

Tie every result to the application, scope, plan version, rule version, inspector, time, and evidence. Separate an observation from a failed requirement and a stop-work or enforcement decision. Corrected data should preserve the original and authority.

Issue understandable decisions, credentials, and appeals

Decision notices should identify the application safely, outcome, reasons, conditions, effective and expiration dates, next steps, assistance, correction, and appeal options approved by the program. Preserve the exact notice and delivery events. Avoid sensitive details in email subjects or unauthenticated links.

Issued permits or licenses need status, holder, authorized activity, scope, conditions, dates, version, amendments, and verification method. Public lookup should disclose only approved fields and resist enumeration or bulk harvesting. A printable credential should not become a bearer token granting portal access.

Design amendments, renewals, suspensions, revocations, reinstatements, corrections, reconsideration, and appeals from the start. Preserve the original record, authority, evidence, and downstream effects. Appeals may require independent review and a frozen decision snapshot. When an outcome changes, reconcile payments, inspections, public status, notifications, records, and reporting.

Build accessibility, records, security, and ownership into acceptance

Use WCAG 2.2 as a shared technical baseline while qualified professionals determine applicable obligations. Test public guidance, forms, uploads, maps, plan comments, payment, scheduling, status, notices, and staff tools with keyboards, screen readers, zoom, voice input, and representative users. Include supported languages, low bandwidth, mobile devices, and accessible document output.

Classify applications, plans, communications, reviews, payments, inspections, decisions, credentials, appeals, and system events under approved records policy. NARA's Universal Electronic Records Management Requirements are a starting point for U.S. federal agencies to tailor with records and acquisition staff; other jurisdictions need their own schedules. Include search indexes, exports, integrations, analytics copies, and backups in retention and disposition design.

Enforce authorization on services, files, APIs, search, reports, exports, jobs, and support tools. Test guessed identifiers, forwarded links, changed representatives, removed staff, malicious uploads, concurrent decisions, duplicate payments, offline inspection conflicts, and restored backups. Define recovery-time and data-loss objectives from public-service consequences, then prove backups through authorized restoration exercises that include files, relationships, identity configuration, payment reconciliation, and records metadata rather than only database rows.

Ask a vendor or developer to demonstrate a difficult scenario: an organization changes representative, a rule changes mid-review, a large plan upload fails, two disciplines request conflicting corrections, payment posts twice, an inspector works offline, issuance is conditioned, public status is queried, and the applicant appeals. A strong solution explains policy version, state, authority, evidence, access, communication, reconciliation, records, and recovery throughout.

Share permit types, jurisdictions, policy sources, applicant relationships, volumes, plans, fees, reviews, inspections, decisions, records, integrations, accessibility needs, and current delays through the project questionnaire, or use quick contact to discuss a focused modernization need.

Authoritative references

• U.S. Web Design System — Complete a Complex Form
• NIST SP 800-63-4 — Digital Identity Guidelines
• W3C Web Content Accessibility Guidelines 2.2
• NARA Universal Electronic Records Management Requirements
• GAO 2025 Green Book — Standards for Internal Control in the Federal Government

Related software planning guides

• Digital Public Service Requirements Checklist
• Digital Public Service Software Cost and Budget Guide
• Emergency Response Coordination Platform Requirements