P124

Engineering Secure Systems with ISO 26702 and 27001

Rhys Evans1, Aggeliki Tsohou2, Theo Tryfonas1 and Thea Morgan1
1

Systems Centre, University of Bristol, UK

Laboratory of Information & Communication Systems Security, University of Aegean, Greece

System engineers are confronted with fast-paced technology developments, complicated contractual relationships, emerging threats
and global security requirements, concerns for sustainability and viability of their ventures and a raft of other issues. In this
environment, information technology-intensive systems in particular are exposed to risk and recent high-profile incidents have
contributed to significant emphasis to be given to security. It is however impossible for systems engineers to become specialists in all
areas of concern in order to be able to tackle effectively those issues and thus architecting systems needs to take into account good
practice and existing relevant knowledge. When such knowledge is embodied into established and widely accepted standards, not only
is there the opportunity to capitalise on their mature content but also to ripe the benefits of compliance, seamless integration and
competitive advantage that standardisation provides. In this spirit we investigate in this paper the use of two popular and established
standards, the ISO 27000 series and ISO/IEC 26702, as aids in the process of engineering secure systems.
Index Termssecurity engineering, standards.

I.

INTRODUCTION

ODAYS complex systems of any kind, be they

intelligent buildings, information systems, or other, rely
increasingly on interdisciplinary collaborative development
approaches and for this reason Systems Engineering (SE) has
become of great importance in recent years.
The definition of SE is described by IEEE as [1]:
An interdisciplinary collaborative approach to derive,
evolve, and verify a lifecycle balanced system solution which
satisfies customer expectations and meets public acceptability.
Where a system is defined as [1]:
An assemblage of objects united by some form of regular
integration or interdependence.
Complexity increases dependency on systems, from
banking, to crime fighting, and retention of medical records.
And as such, their trouble-free and uncompromised operation
is critical for the success of their mission. Security in this
context refers to the protection from exposure to unauthorised
access, use or other exploitation of the system or any of its
elements.
Although International Standards exists for both the
application of Systems Engineering (ISO 26702) and for the
development of dependable, secure information systems (ISO
27001) there is no formal integrated approach based on the
two. This paper will look at developing a framework for
Secure Systems Engineering via process integration of
aspects of both ISO 26702 and 27001. It will look at designing
an Information Security Management System before
beginning a System Engineering project, and how the stages
of the System Engineering Process can be enhanced by
following simple security processes laid out in ISO 27001.
The paper then is structured as follows: Section 2 provides a
brief overview of secure systems and their development,
section 3 outlines ISO 26702 and 27001, Section 4 suggests a
method for process integration of the two standards, and
finally Section 5 concludes the paper.

II.

OVERVIEW OF SECURE SYSTEMS IMPLEMENTATION

APPROACHES: DEVELOPMENT & MANAGEMENT

Insofar three main streams of security practices have

appeared over the years and they reflect largely on
developments in the related security research [2]. To begin
with, the first explicit concerns in regard to systems security
appear around 1960. The practices in question capitalised on
previously accumulated knowledge and thus were empirical
and heuristic, such as extensive security checklists or
countermeasure catalogues. In order to develop the systems
security the security professional was called to choose
practices that were most suitable for the system of concern.
There are specific advantages in similar approaches in the
sense that they may be employed by less experienced
organisations as they embody existing knowledge and offer
solutions to pre-specified problems. They can also form the
basis for the development of good practices (e.g. BSI baseline
handbook [3]) or standards, as in the case of the British
Standard 7799 (2000) that emerged through codes of good
practice. On the other hand, they tend to be abstract and
generic and require further elaboration effort in order to
become tailored to specific organisational needs.
The second stream of security practices originated from
research that flourished in the field around 1980. Then, the
concepts of security risk, threat and vulnerability were
formally introduced in the literature and were embodied in
methods and techniques. This enabled the development of
system modelling-based approaches and tools such as the
CCTA Risk Analysis and Management Method [4]. The
security practitioner could now model the system in question
and tailor the security analysis to the organisations particular
needs.
Whatever the differences between the various methods, risk
analysis and management is separated in two stages, where
each stage is divided into steps. In the analytical stage the
analyst develops an understanding of the system and its
functionality, evaluates its components and assesses its

P124
exposure to various risks. The management stage is introduced
by selecting appropriate countermeasures to deal with the risk
exposure. This approach is usually performed on an existing
IS, and is not easily integrated into the systems development.
That is because at the development stages a systems model is
altering from stage to stage and consequently, this approach is
more applicable to an already developed information system.
Risk analysis and management are techniques that require
expert skills in evaluating the information related risk and
implementing countermeasures on a cost/benefit basis. As
further criticism, IS risk analysis and management are not
regarded as scientific methods, because of their lack of
feedback concerning the specification, design and
countermeasure implementation [5]. Yet they are of the most
popular approaches that practice has embraced.
Both previous streams of practices are characterised by the
fact that they are usually applied after the systems
development. Such a post-applied practices could expose the
system to risk until the security is implemented and also they
are usually applicable to a systems frozen instance in time,
meaning that significant rework needs to be performed every
time that changes are implemented into the system.
Irvine et al. [6], separate the risks of IS in development and
functionality risks. The development risks are separated in
sublime errors that can be handled with quality assurance and
malicious development that can be handled with configuration
management. However, this is not a simple task because of the
limited time to perform it and also due to the associated cost.
For this reason audits are conducted over representative areas
and are targeted and selective.
It is now well over a decade ago since Wood noted a trend
for integrating baseline security features into commercial
products [7]. In such a way the responsibility for the provision
of security is transferred to the manufacturer/service supplier.
Consequently the organisation is responsible of ensuring that
the product is deployed properly and the users are trained for
its use.
However, the majority of existing development
methodologies does not appear to embed particular security
provisions for the system under development. Popular
methodologies such as MERISE, DSDM and the Information
Engineering refer partially, if at all to how the developer will
integrate security features along with the desired functionality.
That is why approaches of the third and most recent research
stream, try to incorporate security requirements within the
development process of information systems. In such a way,
security is introduced early into the system, making it easier to
tackle potential future changes.
In this stream of research, studies are concerned about how
the use of techniques and tools could help in the merging of
the security requirements with the specifications of the IS.
Siponen [8] identifies a duality in these techniques in terms of
their focus to either the modelling techniques (the majority of
proposals) or the development process. From a modelling
point of view, Baskerville [9] proposed the use of popular
diagramming techniques such as Data Flow Diagrams and
Entity-Relationships Models for the specification of security

2
requirements. Other researchers provide modelling extensions
of widely used modelling languages such as the Unified
Modelling Language (UML), in order to accommodate the
security requirements [10].
From a process point of view, Downs et al. [11] present in
their book an interface between CRAMM and SSADM. More
recently, Warren and Batten [12] introduced a complementary
method to be used alongside ETHICS (SIM-ETHICS) and
Evertsson et al. [13] proposed a framework for integration of
security to the systems development process.
There also exist alternative approaches such as the Virtual
Methodology (VM) developed by Hitchings [14], that largely
utilises managerial and problem solving techniques such as the
Soft Systems Methodology [15] for the construction of system
models and the assessment of the risk exposure. In this stream
we can also categorise the Security By Analysis [16]
methodology, developed in Sweden where the socio-technical
system design is popular. It is based on a process of
engagement of the key system stakeholders to analyse and to
consent on the issues of asset valuation, risk exposure and
security controls selection over a series of frequent meetings.
Information security management refers to the structured
process for the implementation and ongoing management of
information security in an organization [17], where risk
assessment is a core element. Risk assessment is the process
that includes risk analysis, thus identifying risks and
describing them in quantitative or qualitative terms, and risk
evaluation, thus prioritizing risk against risk evaluation criteria
and objectives.
In more detail, the objective of risk assessment is to
determine the value of information assets, identify the
applicable threats and vulnerabilities and determine potential
consequences. Finally, risk assessment aims at prioritizing the
derived risks and ranking them against the risk evaluation
criteria. Following risk assessment, risk treatment takes place
in order to determine and implement controls to reduce, retain,
avoid or transfer the risks. Finally, risk acceptance tasks are
conducted to ensure that residual risks are explicitly accepted
by the managers of the organization, and risk communication
activities are implemented so as information about risk to be
exchanged between the decision-makers and the other
stakeholders.
III.

SYSTEMS STANDARDS FOR ARCHITECTURE AND SECURITY

Standardization is the process of developing and agreeing

upon technical standards. A standard is a document that
establishes uniform engineering or technical specifications,
criteria, methods, processes, or practices. The benefits of
standardisation are reflected to a) enterprises by providing
competitive advantage and facilitating trade, b) consumers by
enjoying products and services with specific quality
characteristics, and c) governments by technology diffusion.
In the area of information systems, the advantages of
standardization are two-folded: first, standards establish a
consensus on terminology and thus make technology transfer
easier and safer, and second, they support the common

P124
understanding and agreement of functional and non-functional
requirements, thus facilitating the design of systems that
ensure the compatibility of equipment of diverse origins and
strengthen interoperability.
In the information systems security area, more specifically,
standards support the common understanding of security
requirements and ensure that the security mechanisms
implemented do comply with globally accepted rules and
practices. In this way the systems that are being implemented
reach a commonly accepted security level and interoperate
with other systems in an efficient and secure way
(International Organization for Standardization - ISO).
Therefore, the basic purpose of the information security
standardization is to create a common security model in order
to enable companies to carry out their business and cooperate
globally [18].
A.
ISO/IEC 26702 (IEEE 1220)
The international standard ISO/IEC 26702 Application and
Management of the Systems Engineering Process defines the
interdisciplinary tasks that are required throughout a systems
life cycle to transform stakeholder needs, requirements, and
constraints into a system solution [19]. ISO/IEC 26702 is
aimed at development of commercial product-oriented
systems, such as aeroplanes and information systems, and is
currently utilised globally by industry, government, and
academia [20].
The standard consists of 6 clauses.
1. Scope, purpose, and organization
2. References
3. Terms and acronyms
4. General requirements
5. Life-cycle stages
6. Systems engineering process (SEP)
The SEP (shown in figure 1), consists of eight
subprocesses; requirements analysis, requirements validation,
functional analysis, functional verification, synthesis, design
verification, systems analysis, and control.
Requirements Analysis - Stakeholder input is used to
establish the required system capability through performance
criteria, operational environments, system interfaces and
constraints. Trade-off and risk analyses are conducted to
identify and resolve any conflicts.
The output is a
requirements baseline that contains an operational view, a
functional view, and a design view of the system.
Requirements Validation The requirements baseline is
evaluated against the stakeholder expectations and system
constraints. If the baseline fails to address the criteria then
both Analysis and Validation must be repeated iteratively.
Functional Analysis - The requirements defined during
Analysis are translated into a collection of design elements.
The output is a functional architecture for the system.
Functional Verification The functional architecture is
evaluated against the original requirements baseline to ensure
that it is complete.
Synthesis The verified functional architecture is translated
into several possible design solutions. The optimal solution is

3
selected using criteria relating to budget, schedule,
performance, and risk.
Design Verification - The design solution architecture is
evaluated against the requirements baseline and functional
architecture to ensure alignment.
Systems Analysis A set of techniques to assist with the
three analysis stages, Requirement, Functional, and Synthesis.
These techniques can include conflict resolution, system
effectiveness assessments, and risk management.
Control Tasks are carried out to manage and document
SEP activities and results, this information is used to monitor
progress of the project.
ISO/IEC 26702, initially released as the trial issue standard
IEEE 1220 in 1995 and as a full standard in 1998, has
remained largely unchanged since. A 2007 revision aligned
application of IEEE 1220 practices and processes with the

Fig. 1. The Systems Engineering Process [19].

overarching system life-cycle processes described in the

standard ISO/IEC 15288 Systems Engineering, System Life
Cycle Processes. Combined, these two standards provide
complete technical, management and support process practices
for product system solutions. Both standards are compatible
for use with software standards such as ISO/IEC 12207 or the
IEEE/EIA 12207 series, as well as the ISO 9000 family [21].
A similar standard is ANSI/EIA 632 Processes for engineering
a system, which is far broader in scope than ISO/IEC 26702
(though both EIA 632 and IEEE 1220 evolved out of the US
military standard MIL-STD-499B). The processes it outlines
are considered a subset of ISO/IEC 15288. ISO/IEC 26702
includes an enterprise focus that is lacking in other systems
engineering standards.
Historically ISO/IEC 26702 (or its predecessors) has been
used mainly on large space and military acquisition projects in
the US. Altomare [22] concludes that in general the [systems
engineering] process is now being adopted by some nondefence industries but it has not been generally recognized as
a useful management tool for all types of projects, large or
small, defence or non-defence. This may be due to its
association with large complex Department of Defence or
aerospace engineering projects, or difficulties encountered in

P124
attempting to apply the concepts.. However, according to
Sheard [20], the key systems engineering standards, including
ISO/IEC 26702, have begun to move away from a federal
government contract-centric approach to a commercial,
voluntary compliance approach. The focus has changed from
management to process orientation. The hope is that the
most recent revision (2007) will encourage use of the standard
in more commercial settings and in a wider range of
organisation types, both in the US and globally.
A number of capability assessment tools (e.g. SECM,
EIA/IS 731, CMMI) can be used in conjunction with ISO/IEC
26702. In this way an organisation can monitor and improve
its systems engineering efforts against pre-defined levels.
These levels, once obtained, can be used to demonstrate
competence to clients or stakeholders and to differentiate an
organisation from its competitors. Through these tools
ISO/IEC 26702 can add value to any organisation in the
business of developing complex systems.
B.
ISO/IEC 27000 series (BS7799)
ISO/IEC 27000 series is a family of standards published by
the International Organization for Standardization (ISO) and
the International Electrotechnical Commission (IEC). The
series includes standards that provide best practice
recommendations on information security management, risks
and controls.
The provided guidelines are based on an Information
Security Management System (ISMS) and a process-oriented
approach structured in a circular model (Plan-Do-Check-Act,
fig. 2) for security management. The purpose of such an ISMS
is to ensure the selection of adequate and proportionate
security controls that protect information assets and give
confidence to interested parties. The proposed practices apply
to all kinds of organizations irrespectively of size or type
(commercial, governmental etc.). ISO/IEC 27000 series, at the
moment, comprise from seven standards (Table 1); while two
more standards are under development. Furthermore,
guidelines regarding ISMSs in specific sectors are published;
i.e. ISO/IEC 27011 for telecommunication organization.
The advantages of security standardization are nowadays
recognized by organizations, as it is depicted by the growing
acceptance and adoption of security standards. Organizations
in the United Kingdom (UK) are increasingly utilising the ISO

Fig. 2. PDCA Model applied to ISMS Processes/

27000 family standards for developing their security activities

[23]. The most popular standards of the 27001 [24] family,

4
however, are ISO/IEC 27001 and ISO/IEC 27002; for both
standards an increasing adoption is revealed from surveys [23]
[25], and furthermore, an increase of ISO/IEC 27001:2005
certifications has also be noticed [26].
Briefly, the Plan-Do-Check-Act models main elements
(ISO/IEC 27001, 2005) include: the Planning phase that
TABLE I
THE ISO/IEC 27000 SERIES
STANDARD
ISO/IEC
27000

ISO/IEC
27001

ISO/IEC
27002

ISO/IEC
27003
ISO/IEC
27004
ISO/IEC
27005
ISO/IEC
27006

ISO/IEC
27007
ISO/IEC
27008

FOCUS REGARDING THE ISMS

STATUS

Overview and vocabulary: Assists

organizations of all types to
understand the fundamentals,
principles and concepts to improve
protection of their information
assets.
Requirements:
Specifies
the
requirements for establishing,
implementing,
operating,
monitoring, reviewing, maintaining
and improving a documented
ISMS.
Code of practice: Provides general
guidance on the commonly
accepted goals of information
security management.

Published in 2009

ISMS implementation guidance:

Focuses on the critical aspects
needed for successful design and
implementation of an ISMS.
Measurement: Provides guidance
on assessment of the effectiveness
of an implemented ISMS.
Information security risk
management: Provides guidelines
for information security risk
management.
Requirements for audit and
certification bodies: specifies
requirements and provides
guidance for bodies providing
audit and certification of an ISMS.
Auditing: It will provide guidelines
for ISMS auditing.
Guidance for auditors on ISMS
controls.

Formerly known
as BS7799-part2.
Published in 2005
(a revision is
planned).
Formerly known
as ISO 17799 and
BS7799-part1.
Published in 2005
(a revision is
planned).
Published in 2010.

Published in 2009
Based on BS7799part3. Published
in 2008.
Published in 2007

Under
development.
Under
development.

begins with the definition of the ISMS scope, boundaries and

of an ISMS policy. Moreover, a systematic approach to
information security risk management is determined and
actions for obtaining management approval are taken. Finally,
a Statement of Applicability is developed. Continuing with the
Do phase, the risk treatment plan is implemented and the way
that the implemented controls effectiveness will be measured
is defined. In addition, security awareness and training
programs are implemented, and also operating the ISMS
activities and prompt detection of security events activities
take place. The Check phase aims at continual monitoring and
reviewing of risks. To do so, procedures that promptly identify
attempted and successful security breaches, incidents, and
errors are documented, and also, regular reviews of the ISMS
effectiveness are undertaken. Finally, the Act phase includes
activities to maintain and improve the risk management
process, and also, to take the appropriate corrective and

P124

preventive actions, to communicate the actions and

improvements to all interested parties and to ensure that the
improvements achieve their intended objectives.
IV.

INTEGRATING ISO 26702 WITH 27001 IN ARCHITECTING

SECURE SYSTEMS

Section 3 provided a brief overview of both the Systems

Engineering and Information Security Management standards.
As mentioned in Section 1 we are looking to develop a more
secure approach to Systems Engineering, this section will
discuss a possible way of integrating these two standards to
create a Secure Systems Engineering standard.
The SEP should include the four stages of the ISMS process
at different points in its eight sub-processes. An updated SEP
diagram is shown in Figure 3, with the new stages shown in
bold.
The new process begins with the establishment of an
Information Security Management System (ISMS), this is
steps a-c of 4.2.1 of ISO 27001. This will define the scope of
the ISMS and the risk management procedure for the whole
SE process.
The planning stage of the ISMS continues during the three
analysis steps of the SEP, Requirement and Functional
Analysis and Synthesis. At each of these stages the risks
would need to be identified and evaluated, with options
included for mitigating those risks. This would be following
steps c-g of 4.2.1 of ISO 27001. Doing this would ensure that
the risks associated with every requirement and design
element are taken into account before they go through to the
implementation stages. During the requirements stage each
non-functional requirement should contain, by default,
references to security, so looking at how the requirements
effects confidentiality, integrity, etc.
The systems analysis section is now extended to include the
DO stage of the ISMS, that is section 4.2.2 of ISO 27001. This
would mean that when assessing the requirements, functional
elements and design objects, the risks associated with them are
taken into account. A mitigation plan would then be developed
to reduce, or avoid, the risks associated with each item. This
mitigation plan would then be returned along with the
tradeoffs and impacts for the validation stages.
During the three Validation and Verification stages the risks
outlined in the analysis sections and the mitigation plans
developed in the Systems Analysis section must be reviewed
(Section 4.2.3 of ISO 27001). Doing this ensures that your
risks have been dealt with before you move onto the next
section. A method will need to be developed for deciding on
the residual risk of each section and when it should be
accepted.
As the Control stage of the project is already used to collect
project data and monitor risks, it seems natural to use this
section to perform, in addition to the Monitoring the ISMS, to
also Maintain and Improve the ISMS (Sections 4.2.3 and 4.2.4
of ISO 27001). This would then ensure that risks are being
handled appropriately and that the ISMS is continually
updated and, if need, improved.

V.

CONCLUSIONS AND FURTHER WORK

This paper has outlined the need for a secure approach to

Systems Engineering, i.e. why today we expect our systems to
be of increasing complexity while still maintaining security.

Fig. 3. Extended SEP to include ISMS processes.

We have looked at the current standards for both Systems

Engineering and developing secure systems. It has shown that
neither of these standards is acceptable for Secure Systems
Engineering and that we should look to integrate the two
standards if we are to make System Engineers more security
aware.
The integration approach we defined involved adding
secure development techniques, taken from ISO 27001, to the
Systems Engineering methods, outlined in ISO 26702. This
involves extended the SEP to include the stages of the ISMS at
various point in its eight sub-process. This ensures that an
ISMS is set up before works begins and that risks are
evaluated at each analysis stage of the process. These risks are
then mitigated and checked before work can progress onto the
next stage of the project. The extended SEP is designed so that
it ensures regular checking and updating of the initial ISMS.
ACKNOWLEDGMENT
Rhys Evans and Thea Morgan are Research Engineers
supported by EPSRC funding through the Bristol-Bath
Industrial Doctorate Centre in Systems.

P124

6
REFERENCES

[1]
[2]
[3]

[4]
[5]

[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]

J.M. Tien and D. Berg. A case for service systems engineering. In

Journal of systems science and systems engineering, volume 12 No. 1,
pages 13-38, 2003.
Baskerville, R. Information Systems Security Design Methods:
Implications for Information Systems Development. ACM Computing
Surveys, 25(4), pp. 375-414, 1993.
BSI (2003) IT Baseline Protection Manual. Bundesamt fur Sicherheit in
der Informationstechnik (Institute for Security in Information
Technologies),
material
on
the
web
site
http://www.bsi.bund.de/english/gshb/index.htm, accessed May 2005.
CRAMM. CCTA Risk Analysis & Management Method v5.0, material
on the web site www.cramm.com, accessed May 2005.
Katsikas, S. (1995) Risk Management in Information Systems. In
Information Security: Technical, Legal and Social Issues by Alexandris,
Kiountouzis & Trapezanoglou, published by the Greek Computer
Society.
Irvine, C.E. et al. (2002) An Approach to Security Requirements
Engineering for a High Assurance System. Requirements Engineering,
7, 192-206.
Wood, C.C. (1995) Shifting IS Security Responsibility from User
Organisations to Vendor/Publisher Organisations. Computers &
Security, 14, pp. 283-284.
Siponen, M. (2003) New directions on IS security methods: The process
view. In: Security and Privacy in the Age of Uncertainty, Gritzalis, D. et
al. (eds.), Kluwer Academic Publishers, 325-336.
Baskerville, R. (1988) Designing Information Systems Security, Wiley
publications.
McDermott, J. & Fox, C. Using abuse case models for security
requirements. In: Proceedings of the 15th Annual Computer Security
Applications Conference (ACSAC), 1999.
Downs, E., Clare, P. and Coe, I. SSADM: Application and Context,
Prentice Hall, 1992.
Warren, M.J. & Batten, L.M. Security Management: An Information
System Setting. In: Proceedings of the ACISP 2002 Conference, Batten,
L., Seberry, J. (eds.), Springer-Verlag LNCS 2384, 257-270, 2002.
Evertsson, U., Orthberg, U. & Yngstrm, L. Integrating Security into
Systems Development. In: Security and Privacy in the Age of
Uncertainty, Gritzalis, D. et al. (eds.), Kluwer Academic Publishers,
313-324, 2003.

[14] Hitchings, J. Achieving an Integrated Design: The Way Forward for

Information Security. In: Information Security the next decade, Ellof,
J. and von Solms, S. (eds), pp. 369-383, Chapman & Hall, 1995.
[15] Checkland, P. (1981) Systems thinking, systems practice, Wiley
Publications.
[16] SBA (2005) IT Security By Analysis, material on the web site
http://www.dfs.se/products/sbaeng/, accessed May 2005.
[17] Vermeulen. C., and Von Solms. R. (2002) The information security
management toolbox taking the pain out of security management.
Information Management & Computer Security, 10 (3), 119-125.
[18] Kajava, J. et al (2006) Information security standards and global
business: Proceedings of International Conference on Industrial
Technology (ICIT 2006), December 15-17, Mumbai, India. p. 20912095.
[19] ISO/IEC 26702. Systems engineering - application and management of
the systems engineering process. Technical report, International
Standards Organisation, 2007.
[20] Sheard, S. A. and Lake, J. G., 1998, Systems Engineering Standards and
Models Compared, Proceedings of 8th Symposium of INCOSE,
Vancouver, Columbia.
[21] Doran, T (2005) IEEE 1220: For Practical Systems Engineering.
Computer May 2006 (vol. 39 no. 5).
[22] Altomare, P M, (1996) Implementing systems engineering into an
ongoing programme American Society of Mechanical Engineers,
Dynamic Systems and Control Division, v 60, p 77-79, Engineering
Systems
[23] BERR. (2008) Information Security Breaches Survey, technical report.
PriceWaterHouseCoopers, in association with Symantec, HP and The
Security Company. Available from: http://www.security-survey.gov.uk
[Accessed 8th February 2010].
[24] ISO/IEC 27001. Information technology - security techniques information security management systems - requirements. Technical
report, International Standards Organisation
[25] Ernst & Young. (2008) Global Information Security Survey: Moving
beyond compliance. Ernst & Young. Available from: http://www.ey.com
[Accessed 8th February 2010]
[26] The ISO Survey of Certifications. (2008) ISO Central Secretariat.
Available
from:
http://www.onac.org.co/portal/images/stories/ISO_Survey2008.pdf
[Accessed 8th February 2010].