Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

09.04 Search

SimpleRisk's search story is candid — Core has no global search bar, just per-table filters on each datatable. The Advanced Search Extra adds a topbar search for risks. Here's how to find what you need with what's actually there.

Why this matters

Finding things in a working SimpleRisk install matters every day. The risk you submitted last week, the policy that justifies a control, the asset whose name you can't quite remember, the audit finding that came up in last month's meeting — all of these need to be findable on demand. Search is the tool for that, and the gap between "I can find anything quickly" and "I have to navigate three menus to locate a specific record" is the gap between a usable program and one that hurts to operate.

The honest story about search in Core SimpleRisk: there is no global search bar. The topbar doesn't have a "search everything" input. There's no unified search across risks, controls, documents, assets, and incidents that takes a query and returns matching records from each entity type. Programs migrating from tools that have global search find this surprising. The reality is that SimpleRisk's search surface is per-page, baked into the datatable on each list view: the risk list has its own search, the control list has its own search, the document list has its own search, and so on.

The other thing worth knowing: the Advanced Search Extra is the closest thing to a global search experience SimpleRisk offers, and it's narrower than the name suggests. The Extra adds a topbar search input that searches risk records by their text fields (subject, assessment, notes). It doesn't search controls, documents, assets, or incidents. For programs that primarily need to find risks by free-text query, the Advanced Search Extra is genuinely useful. For programs that need to find anything across all entity types, the Extra doesn't deliver that.

The third thing: per-table search is more capable than it looks at first. Each datatable in SimpleRisk supports a search input that filters the table to rows matching the query string. The matching is server-side and runs against most visible columns. For day-to-day "find this specific risk by partial subject" or "find this asset by partial name" needs, the per-table search is usually the fastest path.

Before you start

Have these in hand:

  • A logged-in SimpleRisk session with permissions for the entity type you want to search.
  • A specific search query. "Find that risk we talked about" doesn't translate to a search; "find risks with 'phishing' in the subject" does. Concrete queries return useful results.
  • An understanding of which list to search. Per-table search means you have to be on the right table. A risk search runs against the risk list, not against the document list. If you're not sure which list holds what you're looking for, the Reports Hub or the entity-specific menu is usually the navigation aid.

Step-by-step

1. Use the per-table search on the relevant list

The most common search workflow uses the search input that's part of every datatable in SimpleRisk. The exact location varies by table but is typically near the top right of the table header.

Steps:

  1. Navigate to the list containing the entity type you're searching. - Risks — Sidebar: Risk Management → All Open Risks (or Review Regularly, Plan Mitigation, etc., depending on the subset you want to search). - Controls — Sidebar: Governance → Frameworks → Controls tab. - Documents — Sidebar: Governance → Documentation. - Document Exceptions — Sidebar: Governance → Document Exceptions. - Assets — Sidebar: Asset Management → Manage Assets. - Vulnerabilities (with the Extra) — Sidebar: Vulnerabilities → Triage Vulnerabilities. - Incidents (with the Extra) — Sidebar: Incident Management → Incidents → Identification (for new incidents) or → Response (for in-progress). - Assessment Contacts (with the Extra) — Sidebar: Assessments → Assessment Contacts. - Questionnaire Results (with the Extra) — Sidebar: Assessments → Questionnaire Results.
  2. Find the search input in the table header. It's usually a single-line text field labeled Search or a magnifying-glass icon.
  3. Type your query. The search matches against most visible text columns of the table; partial matches are typically supported.
  4. The table refreshes (often as you type) to show only matching rows.

The per-table search is the fastest way to find a specific record when you know roughly what list it's on.

2. Use per-table column filters for structured search

Beyond the free-text search, most datatables also support per-column filters. These are typically dropdowns or input fields under each column header that let you constrain the table to rows matching specific values in that column.

Common filter patterns:

  • Status filter — show only Open risks, only Closed audits, only Approved exceptions.
  • Owner filter — show only risks owned by a specific user.
  • Date-range filter — show only items submitted (or modified, or due) in a specific period.
  • Severity filter — show only High and Very High risks.

Per-column filters compose with the free-text search — apply both to narrow the result set further. The combination is what lets you answer "show me all Open High-severity risks owned by Sara whose subject mentions 'cloud'" in three filter actions plus a search.

3. Use the Advanced Search Extra for risk-specific text search

If your installation has the Advanced Search Extra activated, a search input appears in the topbar. This input is configured to search risk records specifically — typing a query and submitting runs a textual search across risk subject, assessment, and notes fields.

The Extra is admin-installed and admin-activated; it lives at simplerisk/extras/advanced_search/. The activation toggles the advanced_search configuration setting and adds the topbar search input.

Steps to use the Extra search:

  1. Confirm the Extra is active — the topbar search input appears only when activated. If your topbar doesn't have a search input, ask your admin whether the Extra is installed.
  2. Type your query in the topbar search input.
  3. Submit. The search returns matching risks, typically rendered on a search-results page that lets you click through to each result's detail view.

The Extra is the right tool when:

  • You're searching specifically for risks (not controls, documents, assets).
  • You don't know which risk list (All Open, Closed, Mgmt Reviewed, etc.) the risk is on.
  • The free-text search needs to span multiple text fields on the risk (subject, assessment, notes).

The Extra doesn't extend to other entity types. For a search that crosses risks and controls, two separate searches are needed.

4. For questions per-table search can't answer, use reports

When the search is more analytical ("show me all risks past their next review date assigned to a specific team"), the right surface is usually a report rather than a datatable filter:

  • All Open Risks Needing Review (/reports/review_needed.php) — risks past their next-review date.
  • All Open Risks by Team by Level (/reports/risks_open_by_team.php) — risks grouped by team, then by level.
  • All Open Risks Assigned to Me by Risk Level (/reports/my_open.php) — risks where you're the owner, manager, or stakeholder.
  • High Risk Report (/reports/high.php) — High and Very High risks across all teams.
  • Dynamic Risk Report (/reports/dynamic_risk_report.php) — configurable report builder for ad-hoc queries.

The report library is broader than the per-table search; for "show me all X matching Y" questions where Y is more complex than a simple text match, start with the reports. See The Built-In Reports for the full report library.

5. For programmatic search, use the v2 API

For automation and integration scenarios, the v2 API exposes filtered list endpoints across most entity types:

  • GET /api/v2/risks (with query parameters for filtering)
  • GET /api/v2/assets
  • GET /api/v2/governance/frameworks
  • GET /api/v2/compliance/... for compliance entities
  • GET /api/v2/im/incident/get/all for incidents
  • GET /api/v2/exceptions/... for document exceptions

The API endpoints typically support filtering parameters that produce SQL-level filters more flexible than the UI search. For scripted "find all X matching Y" patterns, the API is more capable than the UI surfaces and is the right path for any recurring or programmatic search need.

Common pitfalls

A handful of patterns recur with search.

  • Looking for a global search bar that doesn't exist. This is the most common surprise. New users from tools with global search assume SimpleRisk has the same. It doesn't (Core), or it has a narrower version (Advanced Search Extra). Don't waste time searching for a search bar that isn't there; use the per-table surface or the report library.

  • Searching the wrong list. A risk that's been closed isn't on the All Open Risks list. A document marked Retired isn't on the Active Policies view. The per-table search is scoped to the table you're on; if your search returns nothing, check whether you're on the right list. Closed risks have their own list view; retired documents are typically visible via a status filter on the Documents page.

  • Treating per-column filters as the only search. Per-column filters are great when you know the structured constraint (specific status, specific owner). For "find me anything mentioning the word 'cloud'" the free-text search is the right tool. Use both; they're complementary.

  • Activating Advanced Search and expecting it to cover everything. The Extra adds risk-specific text search to the topbar. It doesn't add cross-entity search. Customers sometimes activate it expecting global search and discover it's narrower than the name suggests.

  • Building custom search before checking the report library. A team that builds a custom "show me all open risks by category" surface ends up duplicating what the existing reports already do. Walk the report library first; the seeded reports cover most of the common analytical questions.

  • Searching when navigating would be faster. A user looking for "the SOC 2 framework" might search for "SOC" on the Compliance list. The faster path is Governance → Frameworks (or wherever your Compliance install puts the framework manager) and the framework is right there in the list. Search excels for "find this specific record"; navigation excels for "go to this section." Pick the right tool.

  • Forgetting that search results are permission-filtered. The search returns only records your role can access. A user with risk-management permissions but not compliance permissions searching "encryption" on the risk list won't see encryption-related controls (because they're not on the risk list at all, and the user wouldn't see them on the control list either due to permissions). When a search returns less than expected, consider whether the missing records might be in entities your role doesn't see.

  • Using the per-table search input for "search across all my risks." The per-table search is scoped to the table you're on. To search across multiple risk lists (Open + Closed + Mgmt Reviewed), either run the search on each list separately, or use the Advanced Search Extra (which spans the underlying risk records regardless of which list view they currently belong to), or use the Dynamic Risk Report with a broad filter.

Related