Risk and Compliance Reporting
By Gideon T. Rasmussen, CISSP, CISA, CISM, CIPP
Modern companies are challenged by the need to demonstrate
compliance, mitigate risk and fund security initiatives. Reporting is the
pursuit of simple truth. Like many technical challenges, the underlying
complexity can be daunting. This article addresses a variety of techniques to
report risk and compliance statuses, raise awareness and influence remediation.
Mission / Vision
Document each security function's mission as a first step towards reporting.
Mission can be loosely defined as the high-level goals of a team. A mission
statement explains the purpose of a team from a business perspective. Vision
can be defined as how the team accomplishes its mission.
A basic goal of reporting is to determine the effectiveness and current state
of a given function. It becomes easier to determine at a high-level which elements
should be included in reporting with mission and vision statements in hand.
Reports and Data Sources
Meet with each team or function and request access to their reporting. Critically
evaluate each report. Determine whether reporting accurately reflects status
based upon mission.
At a high-level, risk and compliance reporting should meet the following goals:
· Reflect security posture and the associated risk to core business
products, services and strategic goals
· Consider assessment subjects from a variety of perspectives
· Enable management to make informed decisions
· Provide reporting in a timely manner, preferably through real-time automation
· Identify a point of contact associated with each subject/finding. Accountability
is critical to remediation.
· Support compliance with laws, regulations and contracts
The process of gathering existing reports also identifies reporting points of
contact and data sources. Take note of each. Begin documenting a reporting
methodology at this phase as well.
Risk vs. Compliance
Business management may be of the mindset that compliance is an ideal state,
similar to nirvana. Identify which mandate each control corresponds to. When a
control is tied back to an external requirement, management may support compliance
to avoid penalties.
Risk can be subjective, which is where a well-documented reporting methodology
becomes crucial. Executives want reporting in relatively simple terms. The use of
high, medium and low findings with corresponding red, yellow and green colors is
common. Include supporting data as well. Create a reporting methodology based upon
sound principles, with management as the intended audience.
II. Identify Reporting Types
It is necessary to have well-defined information security standards before
reporting compliance status. Start by establishing a control baseline in
accordance with regulations, laws and contractual obligations. A control baseline
also clarifies policy into specific requirements. Refer to NIST SP 800-53 as an example. Use a control framework such as
ISO 27002 or
COBIT to bolster the baseline.
Conduct a risk assessment to close remaining gaps.
Classify each baseline control to facilitate reporting when findings are present.
Maintain a security awareness
and training program.
Sensitive authentication data
must not be stored after authorization.
Monitor system and network
performance and capacity levels.
ISO 27002, PCI
Data Security Standard
Sarbanes Oxley IT
Determine what types of reporting are necessary based upon mission, audience
and available data. Here are a few examples and free reporting resources for inspiration.
The large number of metrics within the above resources
may seem overwhelming. Create a spreadsheet and sort them by data sources
(teams and tools), audience throughout management tiers and metric
implementation phases. Dan Geer's Measuring Security Tutorial contains a wealth of
information. Refer to it as well.
Compliance is binary, either a control is in place or not. One missing
control will result in a non-compliant status, which does not represent
the risk associated to business. Use risk scoring to assign potential
business impact to each report finding. Start by applying a risk rating
to each baseline control. Refer to the Microsoft Security Risk Management Guide to determine
impact levels and associated exposure ratings. Failure Modes and Effects Analysis has risk scoring
built in. Define which ratings threshold should constitute a control
that is risky and needs to be shored up.
Establish a common reporting language. The meaning and related impact of
high, medium and low findings should be uniform throughout each report.
Refer to NIST 800-30 for sample risk impact definitions.
This interim approach assigns a risk value to each baseline control to
assist with remediation priority. Establish a comprehensive Enterprise
Risk Management Methodology and incorporate it into reporting in a
future phase of development.
II. Implement Appropriate Reporting
W. Edwards Deming said "What cannot be measured cannot be managed".
Business management is likely to be of the same opinion. Establish a single risk and compliance application for the entire company. The
application should accept data from a variety of sources. Questionnaire
functionality is needed to facilitate security self-assessments and
annual security awareness training and testing. The application should
accept data feeds from a variety of sources such as log and security
monitoring software. Security team members will need the ability to
manually enter findings from on-site assessment reports. The application
should also produce security reports to support internal and external
audits such as Sarbanes Oxley and PCI.
Reporting is a data-centric pursuit. Therefore, it makes sense to copy
reporting data to a central repository. From a single location, it is
possible to analyze data and provide reporting. It will be necessary to
have a phased implementation. If a large organization is in scope,
start with a line of business and scale to the enterprise over time.
Duplicate existing reports in the initial phase and add new reports
later. Use role-based access control to restrict reporting to those with
a need-to-know. Monitor manually entered report data to ensure it is
Establish a Risk and Compliance Dashboard
Establish enterprise reporting by management tiers. Reporting should
start at a high-level, detailing risk and compliance statuses for the
enterprise and individual lines of business.
Take care when aggregating enterprise risk and compliance statuses to
provide a high-level executive view. It can be difficult to accurately
accomplish this task due to the complexity of the underlying reporting.
The executive dashboard should also include security metrics and
trending. Management needs the ability to drill down from high-level
reporting to specific issues within underlying populations, subjects
and findings. That functionality is crucial. Include a link to the
reporting methodology document at the bottom of the screen for quick
Consider the Audience
Reporting by tiers is an effective way to present information in a
manner that is meaningful to each audience. Report findings must be
· Company executives want to know the state of risk and compliance
throughout the enterprise. Reporting at this level may be presented
to shareholders and the audit committee.
· Line of Business management needs coordinated reporting from
security teams to understand what the issues are and how they can
impact business. Once an issue is confirmed, it is necessary to offer
a solution, ideally with options.
· IT managers need reporting by population and low-level details
used by their reports to resolve findings.
· Individual contributors need specific findings that apply to the
systems and applications they administer.
Prioritize risk and compliance statuses within each reporting tier.
Work closely with business and IT management to assign a remediation
contact to each finding for accountability. Each finding should also
include details of the issue, planned remediation activity and target
Using the methodology detailed above, an executive should be able to
click down from the line of business, to a high risk subject,
associated findings and remediation plans. In practice, that
functionality is a powerful way to gain visibility and funding to
address critical issues.
III. Present to Management
Finalize the Reporting Methodology document. This article can be used as a framework. Explain the rationale behind each report including data sources such as teams, tools, manual data entry, automation and data refresh periods. Include the importance of risk mitigation over minimum compliance. A methodology document has utility for training, continuity and audit.
Prepare a management slide presentation to introduce the reporting application, executive dashboard and remaining implementation phases. Conduct a live demo of the application during the presentation. Manage expectations up front. Be transparent about current functionality and areas for improvement. Provide a roadmap for future reporting enhancements.
An accurate reporting system is bound to identify high risk findings. Encourage management to foster a culture where high risk findings are permissible, providing remediation contacts and target remediation dates are promptly identified.
Reporting must evolve to adapt to changes in business practices, technology and emerging threats. Keep acceptable risk and compliance ranges tied to a methodology based upon risk and reward (versus tightening ranges as metrics improve). Future phases of development can include feeds from other departments (e.g. audit), inclusion of financial risk reporting and implementation of new metrics.
If a security department does its job well, nothing happens. Business continues to function without disruption or impact. Therein lies the challenge, especially in a tight budget year. Reporting reduces subjectivity and uncertainty. Comprehensive reporting demonstrates the value of the information security program and helps drive future initiatives and funding.
About the author:
Gideon T. Rasmussen is a Charlotte-based Information Security Vice President with a background in Fortune 50 and military organizations. His website is
Originally published in (IN)SECURE Magazine (June 1, 2009)