Various factors contribute to an organization’s ability to effectively report on its continuous monitoring program. Keys to success include a centralized database for risks, controls, and issues data as well as reporting metrics that are customized to the compliance program. AuditBoard’s new ebook, The InfoSec Survival Guide: Achieving Continuous Compliance, explores these and other best practices for reporting on continuous monitoring. Download the full guide here, and continue reading for four best practices to follow for creating a strong reporting foundation.
A centralized database containing the organization’s risk, controls, and issues data is fundamental to an effective reporting foundation. Without reliable data that effectively tracks the status of controls management and issues remediation activities, reliable reporting would not be possible. In addition, the following are some key requisites for creating a strong foundation for reporting on continuous monitoring.
- Define critical events. As compliance events occur, InfoSec must prioritize the ones that will impact the business the most. Defining critical events assigns an appropriate level of urgency to events based on risk, enabling InfoSec and the business to respond accordingly. Defining critical events can also help you structure your reporting frequency, as different areas require daily, weekly, or monthly reporting.
Critical event example:
- High-risk vulnerability is approaching the remediation SLA (14 days to remediate and today is day 13).
- A high-risk vulnerability has exceeded the remediation SLA (14 days to remediate and today is day 15).
- Implement streamlined dashboards. When configured effectively, reporting dashboards act as an alarm system alerting your team to emergencies in addition to tracking the progress of compliance day to day. Ensuring you have such a system that operates as intended is critical for driving continuous compliance. Once you establish your KRIs and KPIs, your dashboards become the source for helping your team make decisions and escalations.
- Chart with the distribution of open vulnerabilities within x days of SLA: 1 day, 7 days, 30 days, 60 days.
- Chart with the distribution of vulnerabilities (by the owner, team, product, system, etc.) over SLA.
- Establish reporting protocols with your team. Once established, your KRIs and KPIs will naturally give rise to a cadence for reporting current standing against a given baseline, target, or goal (or historical reference). Based on this general structure, InfoSec can further build out its reporting protocols. These reporting protocols may include escalating point-in-time insights or summary reports provided to stakeholders at a set cadence.
Reporting protocol example:
- Make metrics to account for critical events (high-risk vulnerabilities must be mitigated within 14 days from severity assignment).
- KRI (# of high-risk vulnerabilities within three days of SLA)
- KPI (# of high-risk vulnerabilities over SLA this quarter)
- Based on your event, create alerts to inform relevant parties to correct nonconformities before or after they happen.
- An alert is sent to the security or engineering team to inform them of the vulnerability three days before its due date.
- An alert is sent to the compliance team to indicate that the vulnerability is overdue.
- The compliance analyst reaches out to the remediation owner to determine why this is delayed.
- Act on the outcomes. The alerting and reporting practices described above enable teams to identify when there is a high number of vulnerabilities approaching an SLA. When this happens, InfoSec should investigate further by asking questions such as:
- Can the organization really mitigate these in time? Does the breach of SLA pose a risk? Why are there so many now in comparison to last month?
- Why are there so many SLA breaches for a given platform? Do we not have enough capacity to mitigate timely? Was the SLA designed too aggressively?
By answering these questions, the team can make improvements to the process and continue to monitor for effectiveness and compliance following their change. To learn more best practices you can incorporate into your continuous monitoring program, download the full ebook, The InfoSec Survival Guide: Achieving Continuous Compliance.
John Volles, CISA, is a Director of Information Security Compliance responsible for managing AuditBoard’s compliance, risk, and privacy obligations as well as helping customers understand AuditBoard’s security posture and position. John joined AuditBoard from EY, where he reviewed and implemented client compliance programs and supporting technologies. Connect with John on LinkedIn.