Project RBC

RBC ISO 27001 · Q1 2026 In review

12 / 147 reviewed · 47 evidence · 12 intake open · due Jun 30

| | Filter:

▾ 🔐 ISO 27001:2022 147 controls · 12 reviewed

5. Organizational (37)

A.5.1 Policies for information security 3/5 AI Not reviewed High 2h ago 5 ev A.5.2 Information security roles and responsibilities 4/5 human Reviewed High yesterday 3 ev A.5.3 Segregation of duties 2/5 AI Not reviewed Med 3d ago 2 ev A.5.4 Management responsibilities — none Not started High — 0 ev A.5.5 Contact with authorities — none Not started Med — 0 ev

8. Technological (34)

A.8.1 User endpoint devices 3/5 AI Not reviewed High 5h ago 8 ev A.8.20 Networks security 4/5 AI Not reviewed High 1h ago 4 ev

▸ 🔐 SOC 2 (Type II) 89 controls · 0 reviewed

Policies for information security

Not reviewed 5 ev mapped · 1 pending

Information security policy and topic-specific policies shall be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur. Topic-specific policies should typically address: a) access control b) physical and environmental security c) asset management d) information transfer e) secure configuration and handling of user endpoint devices f) network security g) information security incident management

Thinking & assessment

Why this version is shaped this way, and what's still open. Embedded here per request — the rationale travels with the artifact.

Decisions locked in this version

Org becomes metadata. Project is the top-level container. The org (RBC, Acme) is a tag on the project, surfaced in the project picker and the sidebar list. No separate "customer" navigation. This matches the data: a consultant's mental model is *which engagement*, not *which customer*. The customer is just *which engagement's tag*.
Framework is a filter, not a nav level. The sidebar no longer goes Project → Framework → Section → Control. Instead the project workspace shows a flat Controls table with Framework as one filter dimension. Default group-by is Framework, so visually it still looks framework-organized — but it's a query, not a place. This matches the data web: one evidence answers controls across multiple frameworks simultaneously, and forcing framework-as-place fights that.
Project workspace is Airtable-shaped. Inside a project, tabs are *views over the same underlying data*: Controls, Evidence, Intake, Mappings (Phase 2), Maturity, Activity, Share. Each is a query, not a separate database. Saved-view bookmarks in the same shape.
Detail-as-peek. Click a control row → peek slides in from the right with the six OOUX slots compressed. Up/down arrows in the peek header walk through the queue. The list stays visible. This matches the work shape: a reviewer goes through 100+ controls in a session and doesn't want to re-load context every click.
Closed projects demoted, not deleted. Last year's RBC SOC 2 collapses under a "Closed (24)" disclosure. Same UI pattern, lower visual weight. An auditor can still pull historic context without it cluttering the active list.

Real-world fit (where this lands well)

Multi-customer consultants. A KPMG associate works on RBC + Acme + Commissionaires in one week. Flat project list with org tags lets them switch context fast without diving through customer → engagement.
Cross-framework reasoning. The aha is "this evidence answers controls across ISO and SOC 2 simultaneously." Treating Framework as filter (not place) supports that. The reviewer doesn't have to choose which framework's lens they're in.
Bulk review through 100 controls. Detail-as-peek + arrow-key navigation through the queue maps to George's journey for Review-mode (100 controls). The queue stays anchored; the detail rotates.
Audience as filter. The top-bar audience toggle still works in this layout. A reviewer arriving via share link gets the same Airtable view, with Intake/Evidence/Activity tabs hidden and the action bar reduced to "Approve / Challenge / Comment."

Where it strains

Consultants used to per-framework UIs may resist. Anouar mentioned an angle where "each individual framework has its own UI." A flat-with-filter approach trades that for cross-framework consistency. If specific frameworks have unique structural needs (e.g., scoping per CPCSC), they may need more than a filter chip can express.
Density. The all-controls table feels heavy at 147 rows + 89 + ... The default *Group by Framework* + *Filter to Not reviewed* makes the in-scope set ~12-30 rows at a time, which is workable. But the empty default would overwhelm.
Org as metadata loses some affordances. "Show me all engagements for RBC across history" used to be Customer → drill down. Now it's a saved view with org filter. Functionally equivalent, but the mental motion is different. May need a "Customers" page elsewhere for relationship management beyond active engagements.
Maturity radar at project level loses framework-zoom. If clients want a per-framework radar specifically (auditor handoff: "show me only the CPCSC posture"), the Maturity tab needs to support both views. Easily done; just noting the requirement.

Still open (not in this mockup)

Reviewer + Client audience filters. The toggle is there; the actual filter logic isn't applied. Each role's view of this same screen needs its own pass.
Mapping queue (Phase 2). Christopher's queue framing as a separate tab. Tab is placeholdered; the view itself isn't built.
Investigate mode. The 100/10 split. In this layout it's a saved view ("Status: Revisit") with a different default sort. Not a separate UI. Worth confirming that's the right shape.
Scoping (per Anouar). Frameworks like CPCSC have scoping rules ("applies to assets matching X"). Where does the scope chip / config live? Likely on the Project header next to "In review." Not yet in the mockup.
Share / Export. The tab exists; the surface for generating share links and customer dashboards is its own design pass.
Empty states. What does this screen look like when a project has 0 evidence and 0 reviewed controls? Day-zero UX is a separate exercise.

The big architectural call this version makes

The data is a web (evidence ↔ controls ↔ mappings ↔ verdicts), not a tree. v1 used a tree-shaped sidebar (Project → Framework → Section → Control) which fought the data. v2 reflects the web: one project workspace, one set of objects, multiple views with filter-and-group as the navigation idiom.

The risk: power users who built mental models around framework-as-place will need to re-orient. The benefit: the cross-framework "translation" thesis is honored at every level of the UI. Christopher's *web → Notion/Airtable* commit lands literally.

If it turns out reviewers really do think framework-first (not control-first), v3 reverts to a tree but keeps the peek pattern. Either way, the OOUX object set stays stable; only the navigation idiom moves.

Files: index.html (v1, tree shape) · index-v2.html (this, web shape) · index-original.html (v1 snapshot, pre-v2)