Information Technology Reference
In-Depth Information
Figure 8.2 shows the IA operations cycle surrounding core and key aspects
of the organization. Core aspects reside at the center of the organization either
figuratively or literally. Core includes data center operations. Core aspects may
include key business functions, people, information, or information technology.
Key aspects of the organization are those that have a direct and significant impact
on fulfilling the primary mission of the organization. Key aspects may reside at the
core and other places within the organization.
Key aspects may also reside outside the organization, for instance, in a managed
service provider (MSP). An MSP arrangement does not mean the organization can
transfer all IA issues to the MSP. At the very least, the organization must provide IA
requirements to the MSP and provide for SLAs that ensure appropriate risk man-
agement. Even if the MSP is contractually obligated for monetary recompense in
the event of a security incident, there may still be a risk of both the MSP and your
organization going out of business if the appropriate safeguards are not in place.
The point is that although an MSP—or any outside service provider—may take on
operational responsibility and a large part of the risk, it does not take on all risk.
There is still a responsibility on the part of IA professionals to ensure that risks to
their organization's interests are appropriately addressed.
8.4
iA Compliance Management program
A comprehensive compliance management program addresses all relevant com-
pliance requirements. Relevant compliance requirements include contractual
obligations, legislation, standards, regulation, policy, strategic objectives, mission
statements, and more. An IA compliance management program identifies, enumer-
ates, and articulates compliance posture for all security-related compliance require-
ments. The first challenge is to identify all relevant compliance requirements—not
an easy task. Having identified the compliance requirements, the next challenge is
to decompose them into manageable categories and elements that serve as high-level
requirements—an even more difficult task. This set of compliance requirements
then becomes the baseline for organizational IA policy, standards, procedures, and
practice, or the baseline for the to-be state of IA compliance.
A compliance assessment compares existing policy, standards, procedures, and
practice (as-is) against the to-be. Differences between the as-is and to-be are IA
compliance gaps. The IA architect and other appropriate business representatives
must review these gaps, identify risks with less-than-full compliance, and recom-
mend steps or methods to address these gaps. Addressing gaps includes explain-
ing why that particular to-be requirement is not applicable to the organization.
Addressing gaps also includes investing in remediation, e.g., IA services and IA
mechanisms to increase security posture, thus increasing compliance levels.
A reasonable question is:
Why even have a to-be requirement if the organiza-
tion is not going to fully comply with it?
Many organizations are subject to legisla-
