Portal projects become risky when “let borrowers see their status” is treated as a complete requirement. Which borrower? Which records? Whose status definition? How fresh is it? What can the user change? What happens when identity recovery or document delivery fails?
Our discovery method turns those questions into a reviewable requirements set. The result is not a compliance certification; it is an engineering contract that the client’s security, legal, compliance, operations, and accessibility owners can approve.
reference flow
The implementation sequence.
- 1
Authenticate
Establish the approved identity, session, recovery, and revocation behavior.
- 2
Authorize
Check every requested record and action against server-side policy.
- 3
Explain state
Show a source-backed status, freshness, responsibility, and next action.
- 4
Exchange safely
Validate document and message operations with scoped storage and references.
- 5
Recover
Provide operational paths for lockout, stale data, failed upload, and unavailable dependencies.
01 method
Start with roles, resources, and decisions.
We create a permission matrix using verbs and records: view application, upload requested document, replace document, view offer, accept offer, update profile, invite another user, and contact support. “Borrower” is rarely enough; an owner, authorized employee, broker, partner, and internal operator may have different boundaries.
Every visible status gets a named source of truth and freshness rule. Derived labels are documented. A user-facing phrase such as “under review” should map to approved source states instead of being inferred from whatever record happened to load.
| Requirement area | Decision required | Failure that must be designed |
|---|---|---|
| Identity and session | Login factor, duration, recovery, revocation | Lost access, expired session, compromised account |
| Authorization | Who can read or change each record | Cross-account access, stale permission |
| Status | Source, mapping, freshness, next action | Provider unavailable, conflicting state |
| Documents | Types, size, scanning, retention, download policy | Interrupted upload, rejected file, missing object |
| Notifications | Channel, consent, message owner | Delivered message points to an inaccessible action |
| Support and audit | Escalation owner and recorded context | User is blocked with no recoverable path |
02 method
Treat documents and messages as their own security boundary.
The application should validate file type, size, and expected relationship at the server. Storage references should be scoped; a guessed URL must not grant access. Malware scanning, encryption, retention, deletion, and legal-hold requirements are decisions for the specific environment, not generic boxes a developer can safely check by assumption.
Messages and notifications need similar care. An email can announce that a task exists without copying sensitive portal content into the message. Deep links should return the user through authentication and authorization before displaying a record.
Implementation checklist
- Document session and recovery behavior.
- Create a server-side permission matrix.
- Map every displayed status to a source and freshness rule.
- Define file validation, storage, scanning, retention, and deletion.
- Specify user-visible errors and support escalation.
- Review keyboard, focus, labels, contrast, and status announcements against the accessibility target.
03 method
Write acceptance tests from the failure states.
Our portal test plan includes the happy path and cross-account access attempts, expired sessions, revoked permissions, back-button behavior, duplicate uploads, interrupted uploads, provider timeouts, stale statuses, missing records, inaccessible notifications, keyboard-only use, and reduced-motion preferences.
The approved security and accessibility targets should name their version and scope. OWASP ASVS can help structure application-security verification, WCAG can define accessibility conformance, and NIST digital-identity guidance can inform identity decisions; none replaces a system-specific threat model or qualified review.
primary references
Sources used for this method.
Vendor and standards documentation can change. Confirm the current version and the requirements that apply to your organization before implementation.
related work