April 20, 2015 | Posted in GRC by Scott Byrum
A useful feature of Archer is the ability to automatically generate findings from compliance or risk assessment questionnaires when questions are answered incorrectly (which may indicate that an expected control is not in place). The screenshot below depicts such a finding (fyi…we’ve altered the out-of-the-box finding fields and workflow a bit). Archer will automatically populate dynamic finding wording into the Finding field and create a cross reference to the questionnaire target (in the “Asset” field) and to the questionnaire itself.
This is a good start but there are several blank fields in the record above. Customers often choose to update the raw records manually before sharing the finding with the owner for remediation planning, risk acceptance, or whatever the workflow may be. Manual updates are not a big deal if isolated to a few finding records but if you’re rolling out several questionnaires you may end up with a large volume of finding records in the format above. For instance, if you roll out a compliance assessment to 50 application owners that contain 50 questions and 10% come back incorrect, you have 250 findings in the format above which require manual update prior to routing the findings to owners for input.
This is where Archer-to-Archer data feeds can come in handy. The two feeds described below update the raw finding record fields with additional information which is already stored in Archer:
- Feed 1 populates the Business Unit Manager, the Manager’s Delegate, and the Business Unit’s Info Sec contact from the Business Units application record (the target of the questionnaire) into the finding’s owner, delegate(s) and facilitator fields. Filters in the feed’s source report ensure that only new finding records that are generated by a questionnaire are impacted by the feed.
- Feed 2 populates the Source, Question Number, Finding, and Recommendation in the finding record from an on-demand application (we call it “Finding Feeder”), which has predefined wording/values for these fields for each question in the questionnaire. To ensure that each finding is only updated once, the feed sets an off-layout field called “Processed by Feeder” in the findings app to “True”. Filters in the feed’s source report limit finding records that are updated by the feed to those that were generated by a questionnaire where the “Processed by Feeder” field does not equal true.
The result is a finding record that looks like this:
Notice that there are no blank fields; the record is meaningful and ready for the owner and delegate to review and act on. It may still make sense to review the completed questionnaire for comments associated with incorrect questions (and incorporate relevant info into finding records) but the data feeds should save significant time especially when dealing with a large volume of finding records.
The use case above is only one example of what’s possible with Archer-to-Archer data feeds. If you’re interested in more detail or discussing other opportunities to use data feeds, feel free to reach out to Scott Byrum at: email@example.com