Mapped Controls by PISF Area, split by Implementation Group
Count of accepted (requirement, control) instances per area — the same control mapped against several requirements is counted once per requirement.
EssentialFoundationalAdvanced
Click an area to filter the list below to it.
Cyber Security Domains ↔ PISF Areas
Every PISF Area draws its selected and additional candidates controls from across the Cyber Security Domains.
Cyber Security Domains
PISF Areas ↔ Cyber Security Domains Mapping
PISF Areas
Mapped Controls by PISF Area, split by Implementation Group (Essential, Foundational and Advanced)
EssentialFoundationalAdvanced
Browse each requirement, adjust which controls are Selected vs. Additional Candidates and at what tier, reorder them, then Save. Save persists your edits; "Mark Reviewed" is separate and just finalizes your review of the requirement currently on screen -- use it once you're done deciding on that requirement, whether or not you changed anything. All Controls / PISF Mapping / Mapping by Area always show the original AI-suggested baseline, unaffected by review changes.
Add a control not already listed below (e.g. Other control mapping or Unreferenced Controls)
0 pending changes
Refine the exact control-statement wording your organization will adopt for each selected control, with AI suggestions grounded in your organization's context and documents, then Save.
Organization Profile used for AI suggestionsSample / placeholder data
Context of Organization
Scope of Organization
Documents (policies, regulations, etc.)
0 statements written
Sample dataShowing the fixture in data/pic_sample.json — the authored catalogue will appear here automatically once the pic_* tables are populated.
The Catalogue views need the local server (run_dashboard.bat) — this static copy has no /api/pic backend.
Sample dataThis record comes from the fixture in data/pic_sample.json.
Sample dataRows come from the fixture in data/pic_sample.json; the workbook's About sheet says so too.
The Catalogue views need the local server (run_dashboard.bat).
One row per evidence item — the list an auditor sends the ministry before fieldwork (plan §3.1). "Proves" names the assessment objectives each item satisfies.
The NCERT-SCF-PCC Mapping has not been built yet. It will map the 315 PISF leaves (governance leaves to PCC controls; technical leaves to NIST 800-53 and CIS controls via SCF 2026.3, up to 5 and 10 controls per leaf respectively).
The Catalogue views need the local server (run_dashboard.bat).
The Catalogue views need the local server (run_dashboard.bat).
The Catalogue views need the local server (run_dashboard.bat).
The Catalogue views need the local server (run_dashboard.bat).
The Catalogue views need the local server (run_dashboard.bat).
PISF id
Control name
Description (verbatim) and leaves
Decision
Sample dataCounts come from the fixture in data/pic_sample.json.
The Catalogue views need the local server (run_dashboard.bat).
EssentialFoundationalAdvanced
The Catalogue views need the local server (run_dashboard.bat).
Parsed the requirements and the SCF control catalog into a structured, addressable form. The mapping was built on SCF 2025.3.1 (1,420 controls) and has since been moved to SCF 2026.3 (1,591 controls): each selected control was replaced by the 2026.3 control that supersedes it, with its tier kept.
Enabled every requirement and every control to be compared programmatically in the steps that follow.
Pass A — Tier every SCF control
Each SCF control (1,420 in the original pass) was independently classified into Essential / Foundational / Advanced.
Done before any requirement was even considered — purely on the control's own merit.
One stable tier per control, applied consistently everywhere it's later mapped — no re-judging it differently for each requirement.
Build tier-balanced shortlists
For each requirement, a shortlist was drawn mostly from its home SCF domain(s), balanced across tiers.
Plus a smaller cross-domain allowance surfaced by embedding similarity — relevant controls from other domains.
Keeps the next pass focused on plausible candidates instead of comparing against the whole catalog at once.
Pass B — Decide genuine matches
Tier was already settled by Pass A, so this pass asks one narrower question: which shortlisted candidates are genuine matches?
Separating relevance (Pass B) from severity (Pass A) let each pass do one job well.
Result: tiers stay consistent across the whole mapping, and matches are more precise since they aren't diluted by tier-judgment noise.
Validate
Cross-checked the resulting mapping for completeness and quality.
Flagged any requirement left unmapped and any control never referenced by anything.
Computed the cross-domain acceptance rate — a signal for how well-tuned the shortlist step was.
Stand up a versioned review backend
Established a permanent, append-only record of the AI-suggested baseline.
Every human review edit is layered on top as a timestamped, attributable change.
The baseline stays intact as a reference no matter how much reviewing happens afterward.
Interactive review loop
Reviewing each requirement's mapped controls.
Re-tiering where the AI's judgment needed correction.
Moving controls between Selected and Additional Candidate.
Adding controls the pipeline missed.
Approving the final control wording for each selected control.
Every save is recorded as its own event, so the full review history stays auditable.
Publish
The current reviewed state is published to the hosted dashboard.
Shareable outside the local environment.
A record is kept of what was published and when, so it's always clear whether the hosted view is up to date.