Reports run through Hitachi ID Bravura Identity, interactively or on a schedule, can be fed back to the request subsystem. This makes analytics actionable, since report output automatically triggers requests for remediation:

  1. Request forms are marked as eligible for being invoked from reports.
  2. A suitably permissioned user runs a report interactively and inspects the output.
  3. The user then selects a request form and maps columns in the report to fields in the form.
  4. Some fields may be set to constant values, rather than report columns.
  5. The report is then re-run, immediately or on a scheduled or recurring basis.
  6. Bravura Identity submits a new remediation request for every row of report output.
  7. Bravura Identity tracks request submission, to suppress duplicate requests to remediate the same thing. For example, if the report was "list inactive accounts" and the request was "disable account," Bravura Identity will only disable newly discovered inactive accounts rather than attempting to repeatedly disable the same accounts, on subsequent runs.

Configuration of a report to stream its output to a request form is illustrated in Figure [link].

Screen shot: actionable analytics -- report output to request input

Screen shot: actionable analytics -- report output to request input

Generating and resolving audit cases

Bravura Identity supports automatic generation of audit cases, when its automated analytics processes identify policy violations or new instances of elevated risk.

  1. "Cases" are just requests in the workflow queue, though not requests for access.
  2. They are generated by a report, whose output is fed back into the request system automatically (one-time or on a scheduled run).
  3. The report infrastructure checks for duplicates and will not re-submit the same case within N days of first submitting a given request.
  4. Cases are automatically 'approved' and routed to the appropriate controls owner to 'implement.'
  5. Implementers accept a case (since more than one person might be invited to work on the same case/request) and mark them as closed when they complete their investigation and/or remediation.

In some cases, it is possible to automatically remediate audit cases, without human intervention. For example, on some applications it is reasonable to disable the right of unused (dormant) accounts to login. Where automated remediation is possible, the configured request type is one for remediation, not for review.