Here
are just some of the relevant factors:
Level
of senior management support. Definitely the #1 factor in my book, as just
noted above. Affects most of the rest of this list. Itself depends on
management’s understanding of what will be or is involved in the
implementation, and what are the business drivers and anticipated positive
outcomes for the organization when the ISMS is in place and certified. Can be
overcome to some extent by information security awareness activities, business
cases, and general schmoozing, focusing specifically on these issues for the
Execs and dealing positively with their concerns. Hint: it pays to work
one-on-one with individual managers, not address just some faceless
“managementâ€.
Level
of middle/junior management understanding and support, particularly in areas
such as IT, HR, Risk Management and Legal/Compliance. Tends to follow #1 but
not necessarily in dysfunctional organizations. Can also be mitigated/improved
through security awareness, schmoozing etc. Make friends and influence these
people by showing them how the ISMS will make their jobs easier and more
effective.
Experience,
capabilities and diligence of ISMS implementation team comprising the team
leader (probably but not necessarily the Information Security Manager) plus
assorted team members. Can be boosted by reading and training, plus of course
this website and the ISO27k Forum. It is also worth considering targeted
consultancy assistance to benefit from others' experiences (both good and
bad!). Includes expertise in project and change management, and political
astuteness: remember this is NOT repeat NOT a purely technical project within
IT!
Organization's
information security maturity level when starting the project, and their
desired goal level when the implementation phase can be considered “finishedâ€.
Usually unstated and difficult to pin down. Worse than that, it’s a moveable
feast that will shift as the project proceeds, typically because improved
information risk assessment processes identify ‘risks and opportunities’ [for
improvement] that weren’t even appreciated in the beginning (ah, ignorance is
bliss) ...
The
organization’s actual/true level of information risk. This factor rather
self-evidently affects the amount and quality of security controls necessary,
and hence the nature of the ISMS required. A military or high-profile
organization in an intensely competitive market or highly regulated industry
will probably end up with a rather different ISMS than, say, a bicycle shop.
Existing
compliance load and experience e.g. PCI DSS, privacy, FISMA and particularly
ISO 9000 or similar ISO management systems expertise within the organization.
The need for compliance with externally-imposed information security-related
laws, regulations, contractual terms etc. may be driving the ISMS
implementation project forwards, but equally this pressure tends to divert many
of the self-same resources from their ISMS implementation activities.
Level
of understanding and support for the ISMS project in related assurance
functions such as IT, risk management, finance, HR, legal/compliance, physical
security, audit, plus key business functions (i.e. the political and commercial
powerhouses of the organization). Make no mistake: if your ISMS does not have -
or at least if the implementation project cannot generate - sufficient genuine
support from these functions, you are stuffed. Ignore this factor at your
peril.
Strategic
fit between the putative ISMS claimed/actual benefits and the organization's
stated/actual business goals. Finding, creating and/or making explicit the
points of alignment (such as obviously shared objectives etc.) can be the key
both to surmounting any speed bumps on the road to ISMS nirvana and generating
ISMS success metrics that management simply cannot ignore.
Number
and power of blockers or barriers - generally this refers to powerful people
within the organization (not necessarily managers!) but sometimes technical
and/or commercial barriers can threaten to derail a project. See #1 and #8.
Resourcing
levels (not just the core ISMS implementation project team!), plus the level of
other competing initiatives and activities. This includes $$$, skilled people,
consultants etc., and I mean the actual level of effort expended on the
project-related activities, not just the budgeted or committed levels. It’s no
good ‘trying to make the time for this’.
Scope of the ISMS e.g. business units to be included, supplier relations included or excluded. Counter-intuitively, perhaps, scope is not a primary factor since a basic level of effort is always required to design and implement the management system, regardless of how widely it is applied throughout the organization. Scoping the ISMS too narrowly-scoped may actually create more work for the implementation team as well as unduly constraining its business value!
String length
User questions & answers