Skip to main content

User Flows — Customer Portal

CUSTOMER PORTAL

Used by the MSSP's clients. Mostly read-only — real inputs are filling assigned questionnaires, uploading documents/policies, building org structure, managing the vendor list, and ticking off remediation steps. Organized as 6 top domains (Compliance, Security, Supply Chain, Training, BCP, Monitoring), each with its own sub-menu. Clicking a domain swaps the left sidebar to that domain's sub-tabs and opens its main dashboard.

Logging in​

  • What it does: Gatekeeps access to the client's portal.
  • What the user can do: Sign in with username + password.
  • How they do it: They enter credentials on the "Client Portal" sign-in page.
  • What happens: On success they land on their Compliance dashboard. If access is switched off or has auto-expired after a year, they see an "Annual License Expired — please contact us to renew" screen and can't enter.

Domain 1 — Compliance​

Compliance Dashboard​

  • What it does: The landing overview of the organization's compliance health — a headline score plus breakdowns by systems, policies, security risk, and questionnaires.
  • What the user can do: Read their overall Compliance Score and Mitigation Progress, see how many systems/policies are analyzed/approved, review assigned questionnaires with completion status, and scan the main compliance tasks.
  • How they do it: View-only — they open the dashboard and scroll the summary cards and progress bars.
  • What happens: The numbers and bars reflect current data and recalculate automatically as work is completed elsewhere.

Compliance Framework​

  • What it does: A single consolidated checklist of every outstanding compliance task — pending questionnaires, pending policy submissions, security vulnerabilities, and a systems work-plan table.
  • What the user can do: See an overall percent-complete bar, expand each category for specific items, click a system row to open its gaps and tick them off as mitigated, and optionally translate a section to Hebrew.
  • How they do it: They expand a category, read the items, and for systems click a row to open a "gaps found" pop-up where they check off each gap.
  • What happens: Checking gaps updates that system's mitigation status and projected score, and the progress bars move. Most rows link the user back to where the actual work is done.

Organization Systems (Questionnaires) — primary client input​

  • What it does: The questionnaire workspace — the main place the client provides information. Lists all assigned questionnaires with status (Pending / In Progress / Completed).
  • What the user can do: Start a pending questionnaire, continue a draft, preview questions, view a completed response, re-edit a submitted one, and upload/manage organization files.
  • How they do it: They click Start/Continue, answer each question (text, choices, tables, file attachments) — work auto-saves as a draft — and click Submit when done; for documents they use the upload buttons.
  • What happens: Submitting marks it Completed and feeds the answers into the rest of the platform — table questionnaires automatically populate the organization's "systems" list used by Systems Analysis, Data Flow, BCP, and more. A confirmation shows and the dashboard counters update.

Organizational Structure — client input​

  • What it does: A form describing the organization: basic details, departments, and roles per department.
  • What the user can do: Review auto-filled details (from their questionnaire answers), edit them, add/remove departments and roles, add/remove whole organizations, upload an org-chart file, and download the structure.
  • How they do it: They expand the sections, type into the fields, and use Add/Remove buttons; changes save automatically.
  • What happens: The saved structure becomes the backbone for training programs per department, BCP impact analysis, process costing, and monitoring. A save indicator confirms each change.

Policies & Procedures (Required Documents) — client input​

  • What it does: Lists the policy documents the client must submit, grouped by set, each with a status (Pending, Submitted, Under Review, Needs Revision, Approved, Rejected).
  • What the user can do: Read each policy's description/guidelines, upload the required document (or a revision), view their submission, withdraw one under review, delete a rejected one to restart, read the administrator's feedback, and open the finalized generated policy for approved items.
  • How they do it: They click "Upload Document," pick a file (PDF/CSV/PNG/JPG only), and confirm; click the Feedback badge to read reviewer notes; click "View Policy" to open the finished document.
  • What happens: Uploading sets the item to Submitted and sends it for MSSP review; withdrawing/deleting resets it to pending. Status badges and the compliance dashboard update.

Document Analysis​

  • What it does: A read-only view of how the client's submitted policy documents were assessed — statuses, scores, and any analysis and annex documents.
  • What the user can do: Browse their compliance documents, see approval status and scores, open analysis details, and view annexes.
  • How they do it: They scroll the list and click a document to expand its analysis.
  • What happens: The analysis is displayed for reading; uploading happens in Policies & Procedures, not here.

Org. Standard Framework​

  • What it does: Lets the client browse the requirements (clauses and annexes) of compliance standards relevant to them.
  • What the user can do: Tick the standards to view, see each standard's clauses/annexes as cards, and click any clause to open its implementation guide.
  • How they do it: They check a standard's box, the requirements load, and they click a clause to read its guidance.
  • What happens: Their selection is remembered. This is reference material; clicking a clause opens an explanatory guide. If an admin hasn't generated requirements yet, it shows an empty state.

Systems Analysis​

  • What it does: Shows each of the organization's systems (from submitted table questionnaires) as a card with its AI compliance analysis, score, risk level, and data classification.
  • What the user can do: Browse system cards, open a system's full analysis report, translate it to Hebrew, and generate/open a printable report.
  • How they do it: They click a card to open the analysis, then use the translate and print/report buttons.
  • What happens: The analysis opens for reading; the report opens in a printable window. The client doesn't run the analysis themselves — un-analyzed systems point them to their administrator.

Data flow & Data classification​

  • What it does: Per-system view of data handling — data types, hosting, database classification, security level, and data-flow detail.
  • What the user can do: Browse systems, open a per-system data-detail form, view/generate data-flow diagrams and required-security-document reports, and view classification and security level.
  • How they do it: They click a system to open its detail form, fill/confirm the fields, and use the report buttons (with a language choice); reports open in pop-ups.
  • What happens: Saved details feed the system's classification and the Systems Analysis/Final Report; generated reports are stored and can be reopened.

Final Report​

  • What it does: The consolidated final compliance report, organized into standard sections (cover, executive summary, legal basis, methodology, findings, remediation plan, management decisions, appendices).
  • What the user can do: See which sections exist, open the full report, open the management-decisions and systems-risk summaries, and print.
  • How they do it: They click "View Full Report" (and the management/risk buttons) to open the assembled document, then print.
  • What happens: The finished report is presented for reading/printing. Sections are produced by the MSSP's work; the client consumes the output here.

Domain 2 — Security​

Main Dashboard​

  • What it does: A visual summary of security posture across all testing types (penetration testing, external surface, code review, security assessment, tools) with risk scores, severity breakdowns, and charts.
  • What the user can do: Read overall and per-method risk scores, view charts, and jump to a method's detail tab.
  • How they do it: View-only; read the cards/charts and click through.
  • What happens: Charts reflect the latest uploaded findings; links open the matching sub-tab.

Security Tools​

  • What it does: Shows the security tooling assessed for the client, grouped by segment (endpoint, network, identity, cloud), with findings and risk scoring.
  • What the user can do: Browse tools by segment, open a finding to read its details, and see risk scores and coverage charts.
  • How they do it: They scroll/select tools and click a finding to open its detail dialog.
  • What happens: Finding details and risk visuals are displayed for reading; acting on findings happens in Workplans.

Penetration Testing / External Surface Attack / Security Assessment / Code Review​

  • What it does: Four report viewers (same design) presenting findings from each type of engagement the MSSP performed. (External Surface Attack is now functional — no longer a stub.)
  • What the user can do: Open each uploaded report, read its executive summary, findings list with severities, and average risk score, and view evidence images.
  • How they do it: They click a file to open its analysis; click a finding/image to enlarge.
  • What happens: The selected report's findings are shown for reading. View-only — the client doesn't upload test files here.

Reports — [PLANNED — not yet built]​

  • Intended purpose: a consolidated security report for the client. Currently a placeholder ("Under Construction").

Workplans — interactive​

  • What it does: The remediation workspace for security findings — track and prove progress on fixing each finding, per method or per tool.
  • What the user can do: Pick a method (or tools), pick a file/tool, mark remediation steps done per finding, add comments, and upload evidence.
  • How they do it: They select a method, choose a file/tool, open a finding, tick its steps, type notes, attach evidence, and Save (also auto-saves).
  • What happens: Progress is stored against each finding and reflected in the Security dashboard and the Monitoring rollups. A Save confirmation appears.

Domain 3 — Supply Chain​

Main Dashboard​

  • What it does: Overview of vendor/supply-chain risk — vendor counts, risk distribution, summary charts.
  • What the user can do: Read vendor risk tags, counts, and charts; navigate to a sub-tab.
  • How they do it: View-only.
  • What happens: Charts reflect the current vendor list and analyses.

Vendor Management — client input (full add/edit/delete)​

  • What it does: The client's vendor register.
  • What the user can do: Add, edit, and delete vendors (name, services, address, contacts, type, risk level, compliance status, contract dates, notes); search the list; copy a vendor-portal link; and (for one authorized account) bulk-import vendors from CSV.
  • How they do it: They click Add/Edit to open a form, fill it, and save; use the search box; click delete to remove.
  • What happens: Saved vendors populate every other Supply Chain tab. A copyable link lets vendors fill questionnaires.

Vendors Questionnaires​

  • What it does: Shows, per vendor, which questionnaires were assigned and their response status.
  • What the user can do: Pick a vendor to see its questionnaires; open a submitted response to view it.
  • How they do it: They click a vendor to expand its questionnaires, then click one to open the viewer.
  • What happens: The vendor's response is displayed read-only. (Vendors fill these via the separate vendor link.)

Vendor Files​

  • What it does: Browse files attached by vendors (via responses or uploaded documents), with optional AI analysis of a file.
  • What the user can do: Choose a vendor, then a questionnaire or document, then a file; view it; trigger/read an AI analysis.
  • How they do it: They drill vendor → source → file via dropdowns, then view or analyze.
  • What happens: The file opens; analysis results are shown/stored for that file.

Systems & Services — client input​

  • What it does: Maps which of the organization's systems each vendor supports, with service-criticality and SLA details.
  • What the user can do: Assign systems/services to vendors, set severity (critical/moderate/basic) and SLA expectations, and save.
  • How they do it: They select systems, set the fields, and click Save.
  • What happens: These vendor-to-system links feed the supply-chain risk view, BCP, and the SCRM policy.

Risk Assessment​

  • What it does: Assesses each vendor against a chosen standard, producing per-vendor gap analyses and scores.
  • What the user can do: Choose a standard, run/view AI risk analysis per vendor, open a vendor's detail panel, and view required vendor requirements.
  • How they do it: They pick a standard; saved analyses load and each vendor's panel can be opened.
  • What happens: Per-vendor scores, risk levels, and gaps are displayed/saved and roll up into Compliance Tracking and the Final Report.
  • What the AI does: Analyzes each vendor against the chosen standard, producing per-vendor gap analyses and risk scores.

Compliance Tracking​

  • What it does: A consolidated view of every vendor's compliance status — scores, risk levels, and the systems each vendor touches.
  • What the user can do: Expand each vendor to see standards analyzed, scores, risks, and linked systems.
  • How they do it: View-only; click to expand a vendor.
  • What happens: Displays the aggregated vendor compliance picture for reading.

Final Report​

  • What it does: A consolidated supply-chain report bringing together vendors, gap analyses, system links, scores, and risks.
  • What the user can do: Read the assembled report and download it.
  • How they do it: They open the tab and use the download button.
  • What happens: The finished report is presented/downloaded.

SCRM Policy​

  • What it does: Generates and stores a Supply Chain Risk Management policy tailored to the client's actual vendor ecosystem.
  • What the user can do: Generate the policy, read it, regenerate it, save it, and download it.
  • How they do it: They click Generate; the system drafts it from their vendor data; they review and Save/Download.
  • What happens: The generated policy is stored and can be reopened, regenerated, or downloaded later.
  • What the AI does: Drafts the Supply Chain Risk Management policy from the client's actual vendor data.

Domain 4 — Training​

(Renamed from "S.E.T" for consistency — S.E.T is the system name. The MVP code still labels this domain "S.E.T".)

Main Dashboard​

  • What it does: Overview of the organization's training posture — average scores by department and by standard, with charts.
  • What the user can do: Read score bands, per-department and per-standard averages, and summary charts.
  • How they do it: View-only.
  • What happens: Charts reflect training programs, sessions, kits, and employee questionnaire submissions on file.

Training Programs​

  • What it does: Builds/views training requirements and per-department training programs for a chosen standard.
  • What the user can do: Pick a standard, generate or view training requirements, generate per-department programs, and open a department's program detail.
  • How they do it: They select a standard, click to generate requirements/programs, and open a department to view its program.
  • What happens: Generated requirements/programs are saved and become the basis for kits and the annual plan; departments come from the Organizational Structure tab.
  • What the AI does: Generates the training requirements and the per-department programs from the chosen standard.

Training Kits​

  • What it does: A library of instructor/training kits, organized by department and standard.
  • What the user can do: Browse kits by department then standard and open a kit to view its contents.
  • How they do it: They drill department → standard → kit and click to open the viewer.
  • What happens: The selected kit opens for viewing.

Annual Training Plan​

  • What it does: A month-by-month schedule matrix of training modules across a two-year horizon.
  • What the user can do: View the schedule grid and open a kit/module from the matrix.
  • How they do it: They read the matrix and click a scheduled module to open it.
  • What happens: Shows the planned training calendar; opening a module shows its kit.

Training Questionnaires​

  • What it does: The training/awareness questionnaires (employee Q&A) available to present or review.
  • What the user can do: Browse questionnaires and open the employee Q&A presenter to run/review them.
  • How they do it: They click a questionnaire to open the presenter.
  • What happens: The questionnaire content is presented for delivery/review.

Submitted Questionnaires​

  • What it does: Shows employees' submitted training questionnaires with scoring and analysis.
  • What the user can do: Browse submissions, view score bands and averages, and open an individual submission's analysis.
  • How they do it: They scroll the list/charts and click a submission to view details.
  • What happens: Submission scores and analysis are displayed and roll into the training dashboard.

Policy Evaluation — [PLANNED — not yet built]​

  • Intended purpose: evaluate training against policy requirements. Currently a placeholder.

Detail Analysis — [PLANNED — not yet built]​

  • Intended purpose: deeper per-employee/per-topic training analysis. Currently a placeholder.

Domain 5 — BCP (Business Continuity)​

Main Dashboard​

  • What it does: A readiness overview for business continuity — incident-response readiness, business-impact coverage, and remediation progress drawn from systems analyses, policies, work-plan recommendations, and the process map.
  • What the user can do: Read continuity-readiness scores and risk labels and navigate to sub-tabs.
  • How they do it: View-only.
  • What happens: Scores reflect current system risk and continuity data; links open sub-tabs.

Process Map​

  • What it does: Maps the organization's operational processes to departments (AI-assisted classification, Hebrew/English aware).
  • What the user can do: View processes grouped by department, auto-classify processes into departments, review priorities, and open process detail.
  • How they do it: They trigger AI classification and review/adjust how processes map to departments.
  • What happens: The process-to-department mapping is saved and feeds Business Impact Analysis, Process Cost, and Monitoring.
  • What the AI does: Classifies the organization's processes into the right departments (Hebrew/English aware).

Process Data Flow​

  • What it does: Per-process detail showing which systems and vendors each process depends on, with flow diagrams.
  • What the user can do: Expand departments/processes, assign systems to processes (manually or via an AI bulk generator), generate process-flow diagrams, set process owners, and view system/vendor summaries.
  • How they do it: They expand a process, pick systems, run the generators, and open diagrams.
  • What happens: System/vendor assignments and diagrams are saved per process and feed BIA, costing, and continuity planning.
  • What the AI does: Bulk-generates the system dependencies for each process and draws the process-flow diagrams.

Process Cost​

  • What it does: Calculates the cost of running each process (people, systems, vendors, overhead) and compares manual vs. AI/automated cost.
  • What the user can do: Enter cost inputs per process (roles/rates/hours, system and vendor costs, overhead, executions per year), use AI estimators to auto-fill, save, view a summary, and generate a cost report.
  • How they do it: They fill the cost fields (or run the AI estimators), then Save; they open the summary and report.
  • What happens: Saved cost data drives the savings figures in the Monitoring dashboard and the cost report; totals recompute live.
  • What the AI does: Estimates the cost inputs and auto-fills the costing fields.

Business Impact Analysis​

  • What it does: A full BIA table per process (recovery time/point objectives, maximum tolerable downtime, operational/financial/legal/reputational impacts, recovery priorities, minimum resources, recovery actions, criticality).
  • What the user can do: Pick a department, view its processes' BIA records, and open a formatted BIA viewer.
  • How they do it: They select a department, load its processes, and open the BIA view.
  • What happens: The detailed BIA is displayed for reading and feeds continuity readiness.

Business Continuity Plan — [PLANNED — not yet built]​

  • Intended purpose: the assembled continuity plan. Placeholder.

Org. Risk Management — [PLANNED — not yet built]​

  • Intended purpose: organization-level risk register for continuity. Placeholder.

Data Recovery Plan — [PLANNED — not yet built]​

  • Intended purpose: data backup/recovery procedures. Placeholder.

Workplan — [PLANNED — not yet built]​

  • Intended purpose: continuity remediation tasks. Placeholder.

Reports — [PLANNED — not yet built]​

  • Intended purpose: continuity reports. Placeholder.

BCP status: the data-gathering half is built and functional (Main Dashboard, Process Map, Process Data Flow, Process Cost, Business Impact Analysis); the planning/output half (Continuity Plan, Org. Risk Management, Data Recovery Plan, Workplan, Reports) is planned but not yet built.

Domain 6 — Monitoring​

Main Dashboard​

  • What it does: An operational/financial monitoring overview by department — process counts, automation status, and projected savings (manual vs. AI cost).
  • What the user can do: Read per-department process counts, savings figures, and an automation pie chart, and open a department to see its processes.
  • How they do it: View-only with a click-to-expand department view.
  • What happens: Figures are computed from the process map and saved process-cost data.

Workplans Management​

  • What it does: A roll-up of remediation progress across the security methods (penetration testing, external surface, security assessment, code review) showing percent-complete per workplan.
  • What the user can do: Select a method and read progress cards (done/total, percent complete) per area.
  • How they do it: View-mostly; they pick a method and read the bars.
  • What happens: Progress reflects the remediation tracked in Security → Workplans.

Compliance Analysis / Security Analysis / Training Analysis / Business Processes — [PLANNED — not yet built]​

  • Intended purpose: cross-cutting trend analyses per domain. All four are currently placeholders.

Monitoring status: Main Dashboard and Workplans Management are built and functional; the four analysis tabs are planned but not yet built.

CROSS-PORTAL FLOWS (Admin ↔ Customer)

The main end-to-end journeys that hand off between the MSSP and their client.

A. Client onboarding & access control​

Admin creates the client and turns access on; sets up their login; the client signs in. If access is off or the annual license lapsed, the client hits the "License Expired" wall — the recurring-revenue control point.

B. Questionnaire lifecycle (the core data-collection loop)​

Admin creates a questionnaire (by hand, AI, or CSV) and assigns it → client fills and submits (with attachments) → admin reviews under Responses, re-opens if needed → client edits and resubmits. Table-questionnaire answers become the client's system/process inventory used everywhere downstream.

C. Document collection & compliance grading​

Client uploads existing policy documents → admin is alerted on the Dashboard, runs AI gap analysis in Compliance Documents, sets a verdict → client sees the updated status and any required revisions.

D. Policy production & delivery​

Admin drafts a client-specific policy with the Policy Generator (AI-written, admin-refined) and approves it → the approved policy becomes viewable/downloadable by the client.

E. Systems / continuity analysis → client visibility​

Client submits table questionnaires listing systems and processes → admin runs Org Systems Analysis and BCP (AI diagrams, gap/risk, impact, recovery plans) → outputs appear in the client's Systems Analysis, Data flow, and BCP views.

F. Security testing → findings → remediation​

Admin uploads security test results (Compliance Scans / Cyber Security), AI extracts and explains findings and produces reports → client views them in their Security domain and tracks the assigned remediation tasks in Security → Workplans.

G. Risk-and-workplan convergence​

Every analysis emits gaps → they converge in Risk Management (mapped to NIST controls, accept/mitigate/transfer/avoid) and Workplans (assignable, trackable tasks with AI-estimated effort/cost) → tasks surface to the client in their Workplans/Monitoring views.

H. The final report​

Admin compiles everything into a formal PDF in Reports (one selected language — Hebrew default; English/Arabic/Russian/French also available) → client downloads it from "Final Report" — the headline deliverable.

Status & remaining placeholders​

Both portals are now documented at full per-tab depth. The only items not described in full behavior are the genuine [PLANNED — not yet built] placeholders in the current code:

  • Security: Reports
  • Training: Policy Evaluation, Detail Analysis
  • BCP: Business Continuity Plan, Org. Risk Management, Data Recovery Plan, Workplan, Reports
  • Monitoring: Compliance Analysis, Security Analysis, Training Analysis, Business Processes

Each is listed with its intended purpose; full four-part detail will be added when those screens are built.

Next: final wording pass, then insert both portal sections into the formal document (docx) as the closing user-flow section.