Creating Security Standards - Context, Structure and Must-Have Content

21/7/2020 Creating Security Standards: Context, Structure and Must-Have Content
Licensed for Distribution
This research note is restricted to the personal use of Celenia Varela

(celenia.varela@avianca.com).
Creating Security Standards: Context, Structure and Must-

Have Content
Published 8 May 2019 - ID G00363608 - 88 min read
By Analysts Mike Wonham
Initiatives:Security and Risk Management Programs for Technical Professionals
Security and risk management technical professionals must create clear, usable security
standards to address risks effectively. This guidance shows how to write standards, select
controls based on scenario risk and build the processes that keep the governance relevant to a
changing environment.
Overview
Key Findings
■ Security policies and standards reflect an organization’s default level of risk acceptance, with
standards addressing the risk appetite for individual projects only.
■ The level of risk relates to the value of the asset and its context. Standards should be written to
address various use cases, reflecting asset sensitivity, criticality and location.
■ Security standards form only part of a good governance process. You need policies, architecture,
education, monitoring and procedures for effective risk management.
■ There is no perfect number for the standards an organization should have. The number varies with
needs for readability, review and ease of maintenance.
Recommendations
Security and risk management technical professionals tasked with building security control
requirements and standards in their organization should:
https://www.gartner.com/document/3913368?ref=solrAll&refval=256968945 1/59
■ Define control requirements as a function of data classification and context, modelling threats to
understand risks. This approach will address most use cases for standards development.
■ Choose controls based on risk, not because a third-party standards organization lists them. An
annotated controls framework is a useful starting point, but rarely suffices long term.
■ Address concerns selectively. Security standards usually focus on confidentiality rather than
availability or integrity, which are typically part of enterprise, not security, architecture.
■ Continuously review standards and change as required through a formal process. You may need to
allow specific, time-limited exceptions, or set lower standards to balance risk and functionality.
■ Build support for security standards within SME teams by involving them to develop appropriate
control requirements. Their operations will initially be the most disrupted by new demands.
Problem Statement
The purpose of a cybersecurity program is to reduce the frequency and impact of security breaches.
Internal security standards provide an organization with the minimum requirements and guidance on
how to protect the organization’s assets. These standards form part of a wider set of security
governance and program management that support a mature approach to security and risk
management. Additionally, they provide compliance and stakeholder assurance. External drivers,
such as a customer requirement to be compliant or certified by a public standard, or otherwise
audited, invariably require organizations to put in place such governance.
Governance is therefore hugely important to the organization. However, there are two problems to be
overcome to create and maintain a coherent, relevant and effective set of policies and standards.
First, they must be structured and written so that they are accessible to the people who need to use
them. Second, they must clearly tell people what they can and can’t do, avoiding ambiguity or doubt.
Structuring the Governance

There are various approaches to creating broad security governance documents, many of which can
result in requirements that are confusing rather than clear and actionable. Gartner reviews many
security governance documents for clients and sees some common issues. For example:
■ Writing a single document that attempts to be all things to all people, rather than targeting
documents to specific audiences. Such a document will typically be too long and have sections of
high complexity, deterring many readers from even completing the first page.
All governance documents will need to target either “everybody” (for policies) or subject matter
experts (for standards and other detailed documents). SMEs will include groups such as
operational staff, architects and developers.
■ Adoption of an external standards framework (such as ISO 27002 or NIST 800-53) as a “policy,”
sometimes without any risk assessment, and relying on short additional comments to clarify
specific requirements. Such a document rarely has relevance outside of the specialist teams using
it. It doesn’t communicate to the wider user community, nor does it necessarily reflect the risks
faced by the organization.
Standards frameworks should be applied as part of a business needs assessment, documented in

security policy and standards. The technical application and determination of patterns and
solutions is part of security architecture. See “Improve Your Security With Security Architecture”
for more insight.
■ Documents that fail to use clear language to define the minimum acceptable requirements and
differentiate them from guidelines. Poor use of language can lead to ambiguity and lack of control.
Security governance should comprise of different types of documents targeted to different

audiences. The responsibility for creating and approving such documents varies with the type of
document. The focus of this research is on the “security standard,” as illustrated in Figure 1.
Figure 1. Security Governance Structure
The structure shown in Figure 1 should be considered a long-term goal. Creating a clear and
cohesive set of documents that covers all the security and risk management requirements of the
organization takes time, consultation, insight and resources. Many organizations start with a single
document, usually focused on the general user population, and then evolve into a more structured
approach addressing specific audiences and issues. There is nothing wrong with this. All
governance, including standards, must continually evolve, whatever the starting point.
Do not assume there is a common “maturity curve” for security policies and standards. This implies
that one approach is best for all situations. Some clients have just one document, such as an
“Acceptable Use Policy,” and may have only a few related documents, if any. This is a good fit for
some organizations, for example, those with little IT infrastructure, low regulation overhead or risks
that are easily managed with simple controls. Others add a data classification policy or data handling
policy, providing more clarity to users about asset value and care. Others may then include a
standards document that starts to be more specific about how or what controls must be
implemented. Finally, some clients have highly evolved and complex document sets that incorporate
policies, standards and procedures.
If your organization has no formal security policy or standards, it must

certainly consider developing at least a basic policy.
Simply adopting an off-the-shelf approach is not enough. A security framework is only a framework.
You must develop the detailed standards, architecture, solutions and governance to implement it in a
way that meets your needs. This is the difference between a security framework such as NIST 800,
NIST Cyber Security Framework (CSF) or ISO 27001 and internal security standards or other artifacts.
Internally created material can leverage security frameworks for structure and ideas but is specific to
the organization. Security frameworks invariably contain guidance on implementation and
customization. This typically includes requirements to perform risk assessment, create internal
standards, and develop architectural standards for implementation.
The exact approach taken should be determined by the organization. The level, complexity and style
of the documentation should match the situation, rather than trying to meet an arbitrarily high and
complex standard. Organizational size undoubtedly drives a slightly more complex approach, if only
because there’s likely a significant IT and application unit. But organizational complexity, where
different business units have different IT, risk and regulatory requirements, can be equally impactful
to this process.
Approach selection for an organization depends on several factors, including:
■ Data and the regulated environment
■ Risks and threats to the business and its stakeholders
■ Complexity of the IT environment
■ Need for certification or compliance with a standards framework, such as NIST CSF or ISO 27001
■ Risk management approach adopted
■ Style of management and culture
■ Organizational structure
■ Security and incident history
■ Organizational culture and preference
Policies and Standards — a Clarification

The words “policy” and “standard” are often used to mean similar things — a document or rule that
says what must or must not happen. Both form part of organizational governance, but the difference
between the two is important.
This research is focused on creating standards. Standards contain a level of detail, closely related to
architecture, that is not directly relevant to many individuals in the organization. The prime audience
consists of technical professionals tasked with developing solutions that meet the organizations risk
management objectives.
Where this research mentions policies, we refer to governance that is strategic and outlines the
direction the organization wishes to take for particular issues. Policies normally apply to all
employees, contractors, and other participants in the organizational operation, and are written
accordingly.
This document assumes that some higher-level policies are in place that provide direction and
boundaries for standards, as indicated in Figure 1. If this is not the case, then it’s still possible to
write standards that are meaningful, but it highlights a gap in organizational governance that must be
resolved. Gartner research on policy development is provided in the Gartner Recommended Reading
section.
The Importance of Classifying Data

Classification, the categorization of data and systems that store and process data according to its
sensitivity or other factors, is crucial to effective security governance. Building a security
architecture, prioritizing risk, and determining acceptable behaviors and required controls needs
categorization to be manageable. Without it, security controls are either determined individually and
per project or may be applied universally. Either way, security will not be targeting the specific risks
and threats the organization faces in such a way as to reflect the value of the assets. As a result,
there is likely to be a mismatch of security effort and expense compared with the threat management
outcomes achieved.
Gartner research covers the development of data classification policies, which describe how an
organization’s data should be categorized and, broadly, what that implies for the end user. Details on
policy creation can be found in the Gartner Recommended Reading section of this document.
Additional information on how classification affects the technical professional can be found in
“Improving Data Security Governance Using Classification Tools” and “Building the Foundations for
Effective Security Hygiene.”
This research demonstrates how to use data classification as a fundamental factor in determining
security control requirements. It is possible to create security standards without categorization, with
the caveats described above. While we strongly recommend that you organize your control
requirements and development of standards using classification, we recognize that you may not be
in an immediate position to do so.
If you are in this situation, follow the guidance and build security control requirements based on your
understanding of the risks and threats your data assets face. Use pre-existing information about the
value, importance or criticality of systems to help prioritize and set levels. If possible, use forms of
classification such as finance, client or intellectual property to help break up the problem.
Deciding the Governance Level

The difficulty for technical professionals tasked with writing standards is deciding what is and is not
an acceptable practice or configuration, that is, what the content of the standards should be.
Security standards set the minimum requirements for protecting an asset

within a context (a scenario). They proscribe or prescribe the use of
technologies, architectures, specific tools, designs, services or processes to
meet the scenario risk.
The answer lies in combining a best practice approach and a risk management approach. This
concept is defined and illustrated in “Building the Foundations for Effective Security Hygiene.” Figure
2 expands that concept specifically for building security standards, showing how the key governance
components influence each other. This positions the internal security standard as a boundary for
security architecture decisions, shaping them to meet the business risk appetite.
Figure 2. Positioning the Security Standard
Enterprise security policies, at a high level, dictate the bounds of what is acceptable. They inform all
other processes:
■ Risk management: Risk acceptance decisions are limited and influenced by corporate policies,
which codify the organization’s attitude to risk. They also indicate risk ownership and business
responsibility. The policies typically don’t give specific insight to risk values or how to address
detailed situations. Instead, the risk management process contributes to those decisions through
risk assessment. Risk assessment of standard use cases can be embodied in the security
standards.
■ Security standards: Figure 1 shows that security standards are more technically detailed and
prescriptive than policies. They should be written to ensure that activities subject to the policies
and standards are performed in a way that minimizes risk to acceptable levels and complies with
the broader policies.
■ Controls framework: Frameworks such as NIST CSF provide both a pathway to developing a
security strategy and lists of possible security controls. The use of a framework may be
organizational policy or may be driven by business scope (such as credit card payments requiring
Payment Card Industry Data Security Standard [PCI DSS]). Security standards should reflect the
framework if one is selected (or required) for use. Avoid using framework control lists as off-the-
shelf security standards. Without risk and other considerations, the list of controls cannot be
shown to apply to your context. It needs customization.
Other factors that determine what the security standard might include are:
■ External drivers such as regulations or contracts can dictate or imply the minimum standards
required by the organization, depending on how prescriptive they are.
■ Internal concerns such as risk appetite or culture will influence the contents of standards. These
should also be reflected in a risk management framework and security policy. Where formal
approaches don’t exist, try to address the concerns directly in the governance that is being written.
■ Business needs and IT context describe the internal environment. Investing in the development of
a standard that addresses a nonexistent IT problem or, worse, disrupts the business, is not a
desirable outcome. Sometimes regulation and business requirements are in conflict. This is not
something to be solved in security standards until the business has made a risk-based decision on
how to address the issue. For an example of how to address such scenarios, see “Understanding
the Implications of GDPR for the Technical Professional.”
The Gartner Approach

The Gartner approach to building security standards encompasses both a framework for the
document structure and an approach for developing the control requirements. Different
organizations will develop different detail and document structures but need to ensure a consistent
logic and approach. As is often the case, the key is getting the process of development and
maintenance right. That is the focus of this guidance.
The Guidance Framework

The Gartner process framework for building and maintaining security standards is shown in Figure 3.
It is a cyclic process because security standards will need to evolve as the business, technology and
environment changes. Therefore, the “final” process component of governance feeds back to each of
the other components to enable continued development of standards that maintain an acceptable
level of risk.
Figure 3. Gartner Process Framework for Security Standards Development
Prework
There is a reasonable level of prework necessary to allow the security standards process to be built
on a solid foundation. The technical professional tasked with developing standards must confirm
that the prework has been completed.
The key message of this section is that security must not develop standards in isolation. This applies
in two ways.
First, standards need the higher-level policies and security charter to be in place to provide the
necessary scoping, risk statements, user information and structure. Developing security standards
without top-down cover can easily lead to a lack of acceptance and the necessary support to
maintain compliance. See the recommended reading for developing security charters and policies
that help to provide this cover and develop the necessary culture.
Second, security standards that are developed solely by the security team invariably lead to two
outcomes:
1. The various teams trying to implement business solutions find themselves in difficulties because
of the strenuous nature of the requirements. This leads to frustration, a poor reputation for
security and increased cost to the organization.
2. The security standards are ignored. This can and will lead to problems for assurance and
compliance monitoring, as well as implying that the risk management process will be unable to
effectively manage risk.
Either way, you must work with other teams to make sure you address the various security, risk and
functional business requirements. Because they are the mandatory elements of the security
governance framework, they must be acceptable to all stakeholders.
The prework shown here will help socialize the development of security standards by:
1. Ensuring the resulting standards are acceptable and reasonable as they were derived through
collaborative effort.
2. Recognizing, including and reflecting business and technical team concerns about achieving their
goals within the constraints of security requirements.
3. Using the organization’s risk management process as a driver for defining standard minimum
controls.
4. Providing a strong basis upon which security architecture can be developed. (See “A Guidance
Framework for Establishing Your Approach to Security Architecture.”)
If possible, ensure that some form of risk management process, however

basic, is in place before starting to develop security standards and
guidelines.
Identify Standards Committee and Contributors

The standards committee (or equivalent — the name is not important) prevents the process being the
sole responsibility of one individual. It provides oversight, many-pairs-of-eyes review, activity
prioritization, quality control and ongoing advice on any ambiguities. Crucially, it also provides the
formality necessary for the standards that are produced to be considered authoritative within the
organization. Figure 1 shows that policies and the charter need board-level approval. Gartner’s
research reaffirms this understanding (see the Recommended Reading section for more insight).
Standards also need approval, but not necessarily at the board level. The standards committee may
be given the necessary delegated authority to approve standards. The committee will also perform a
useful role in creating and maintaining a roadmap for the development and maintenance of the
standards.
The committee should be composed of individuals who are:
■ Competent at understanding core security and risk concepts, without necessarily being security
experts.
■ Selected from a variety of relevant technical domains, including enterprise architecture, security
architecture, infrastructure, applications and development.
■ Supported by their management to invest a portion of their time in this ongoing program.
Notice that the standards committee is, importantly, not the security team. Security standards (and
architecture) dictate how nonsecurity systems should be implemented and protected so that they
only introduce acceptable risk. The security team cannot and should not dictate these standards to
the technical teams who are tasked with implementing them without including those teams in their
development.
Security is often perceived as conflicting with other requirements. Resolving

this takes a collaborative approach between the security team and those
architectural and implementation teams tasked with delivering technology to
meet business requirements.
The committee should convene in some form on a regular basis, frequently enough to be able to
promptly address issues. Initially, this might be a monthly activity, but as the documents are
published and the organization moves into a continuous review cycle, this may be reduced to
quarterly.
The committee should be reasonably formal. Decisions are being made about the content of
standards and these decisions should be properly recorded and minutes shared. At some point, the
standards will need organizational approval and may be challenged by other stakeholders. Because
this process is part of the broader organizational governance, proper record keeping is important for
accountability.
While the committee is responsible for making decisions and setting the direction, there are many
others in the organization who may have an important contribution to make. The application
developer contractor who has “seen this before,” or the engineer with long experience in managing
firewalls elsewhere can be your most valuable contact. How many contributors you work with
depends on their availability and your time, but you should always make sure that you gain input for
each standard you develop.
There are three types of contributors: technical, business and functional.
Technical contributors can offer support in various ways:
■ Previous experience of security standards that have helped or hindered their work.
■ Detailed understanding of the technical domain and what they need to achieve their objectives.
■ A view of “the possible” within their environment, helping you to avoid situations where the
standard demands the unachievable.
■ A view of known risks and issues that need to be managed.
■ Assistance in drafting related procedures and processes that may be required because of
standard.
Business contributor support includes:
■ Defining the business requirements for processing data or other technical activities. This may
include performance, availability, user needs, third-party access and boundaries for processing.
■ Identifying the relevant regulations for their business process and helping to highlight the
compliance requirements that may be addressed by security controls.
■ Assessing whether and to what extent a proposed control impacts their requirements.
Functional contributors support includes:
■ Ensuring critical dependencies are in place.
■ Providing legal or other expertise for interpreting external and client requirements.
■ Supporting processes that help constrain unapproved behavior (such as purchase of shadow IT).
■ Keeping personnel lists and processes reliable.
Functional contributors provide an important role. “Building the Foundations for Effective Security
Hygiene,” shows how they provide critical dependencies for security effectiveness. They have an
equally important role in supporting and contributing to security standards.
Security standards must not just create an environment in which the business and its supporting
technology can operate effectively. The standards must also be realistic. Consider this requirement:
“Only full employees registered with HR as approved for access to secret data may be granted such
privileges.” This is a meaningless statement unless HR has a reliable and trusted process for such
registration and approval. Maintain a close relationship with such teams to ensure that such
dependencies can and are being met, to avoid your standards quickly falling into disrepute.
Early and regular communication is key to success. Agree a communication regime that allows you
to continually test control proposals early in the process, avoiding delays in subsequent stages.
Consider an internal website or blog and use email judiciously. Remember that some of the
information shared may be considered sensitive, and if so, only publish using controlled means, such
as an authenticated internal website.
At a minimum, start and maintain an informal discussion with stakeholders

you can identify. Smaller organizations especially may not have enough staff
to survive a large number of committees.
Identify Influences and Constraints

It is a fact of life, unfortunately, that security does not have a free hand in specifying controls,
processes system configurations, architecture or the use of third parties. All security decisions are
made in the wider context of ensuring business functionality can continue (preferably efficiently), and
external requirements (such as regulation) are met. The technical professional writing security
standards must ensure those standards support these business, external and other requirements.
IT Context
Security standards must directly address the risks introduced by using IT within the organization. You
will need to understand your enterprise architecture, and why it is the way it is, to be able to draft
relevant standards.
For example, when defining that applications must implement a control, consider that applications
must support that approach, or that they must be rebuilt/replaced to do so. Replacement or
rebuilding may have a significant impact and might mean that some controls are not achievable
without considerable effort, if at all. In this case, you will need to draft standards so that future
implementations of IT are required to comply, whereas current ones are granted a risk-based
exception, perhaps with conditions. But you will need to understand expected timelines, and the
future of the enterprise architecture to enable expectations to be set appropriately.
Externally, the organization will be subject to a variety of regulations or requirements to comply with
some standard, such as PCI DSS, or contracts signed with clients. These external drivers, which are
unavoidable, set minimum requirements that your security standards will need to reinforce and
describe in your local context. Do not assume that security knows all these drivers either generally or
in detail. Privacy regulations are a case in point. Privacy is a legal problem, not a security one,
although security has its role to play in achieving compliance. This is where the committee and
contributors are so valuable.
Procurement can help understand what clients and suppliers require from the organization, such as
protected email, access control to data, or some form of remote access to parts of the corporate
network.
Legal and privacy can help identify the key parts of which regulations apply to the organization and
may have an impact on security control requirements. Invest time in gaining these insights and
building the relationships necessary to maintain them. Many basic controls can be written into
security standards without them, such as anti-malware requirements. But even basic controls may
have specific implementation requirements resulting from these external forces. An example would
be when a client contract requires you to implement a specific anti-malware tool and notify the client
for specific incident types. Compliance with such requirements is crucial, so clear understanding of
what is required is a key part of ensuring an effective security standard.
Involve Risk Management Process

Security standards are inextricably linked with risk management and compliance to regulations.
Standards should set control requirements that, if complied with, should result in any individual
project introducing at most the maximum acceptable security risk for the organization.
Note: This risk is per project, system, application or service. While configuring an individual system to
the minimum standard may mean no review is required, there will still be residual risk, even if it is
deemed acceptable. Thus, each project contributes to the total risk the organization faces. Although
this combined risk is unlikely to materialize as a single issue, the organization must maintain visibility
both to the total and individual risks it faces. The risk management process measures and records
this risk through the risk register. The risk register informs security standards, and records how
enterprise and security architecture will address relevant issues. The risk register also informs
enterprise and security architecture about the risks that need addressing both in the short and long
term (see Figure 2). Security standards contribute to the insight by providing baselines to which
compliance levels can be measured.
When a project cannot comply with the security standards or introduces a use case that is not
covered by the standards, it may introduce new risk. Technical professionals must be told how to
recognize this and how to initiate a risk assessment process, perhaps through the project
management process. The immediate result may be an approval by exception, possibly requiring
additional security controls to meet the identified unacceptable risk. Longer term, repeated issues
recorded in the risk register may drive a change in the security standards. Alternatively, the risk may
be deemed too high, even after specific treatment, necessitating a change in project approach.
Therefore, a formal risk assessment process and recording system, along with a reliable asset
register, is critically important. Together with standards and policies, risk management comprises the
complete set of security governance. Please see “Planning and Executing Successful IT Risk
Assessments” and “Building the Foundations for Effective Security Hygiene” for further insight.
Determine Control Requirements
The next stage is to determine the minimum control requirements the organization has. The higher-
level security policies dictate the boundaries, direction and risk appetite. The standards codify that
into technically relevant detail that will allow architects to determine implementation approaches.
Here, the technical professional will look to identify the different domains that require controls,
structure the standards logic, and define the minimum control requirements in those domains. The
deliverable at the end of this is a detailed list of what users and other technical professionals must
do to be compliant with the organizational requirements. It may also identify where specific
procedures must be followed. Although the development of those procedures is not in the scope of
this program, if there are resources and a perceived need to document a specific process, then do so.
This section is not about writing the final documents that will be published and form the actual
governance. But it is likely that draft documents will form the main component of the deliverable.
Identify the Domains for Coverage

It was highlighted earlier that a single documented standard for security may be appropriate for
some organizations. But for many, a set of structured documents is more effective both in
communicating requirements and maintaining the standards.
Regardless of how you decide to write the standards (see the Write Standards section below), you
will need to be clear in the controls that apply. To do that, you need to understand the environment
you are controlling. The best strategy is to divide the problem into subsections or domains, typically
dividing standards by a combination of enterprise architecture and security control domains.
Enterprise and Security Technology Architecture
Your technical infrastructure will be composed of many hundreds and thousands of discrete
components. These will include systems and network devices, applications, cloud services, third
parties and user devices. You cannot write a security standard, let alone maintain it, for every
individual type of device. Instead, you will need to categorize devices and infrastructure so that a
consistent control requirement can be applied to similar devices or circumstances. Examples are
given in Table 1.
Table 1: Enterprise Architecture Approach
Device
Group/Domain Notes
Examples
Servers Windows, Server operating systems may be unable to implement

Linux, equivalent controls because of technology limitations. As a
mainframe result, mainframe security is often dealt with as a separate
servers problem.
Device
Group/Domain Notes
Examples
Network Switches, Different network devices have different roles and capabilities
routers, to be secured and implement security. Networks are made of
firewalls individual groups of these devices that create zones of trust.
Applications Commercial- Applications vary in capability and need to support security

off-the-shelf controls. A single standard for all applications may drive
(COTS) and excess exception requests. Building standards into
custom procurement and development processes is a strong
applications supportive approach.
Cloud Services SaaS services SaaS environments vary in their security capabilities, but by
(SaaS) of all sorts using cloud access security brokers (CASBs) and identity and
access management (IAM), a baseline standard of minimum
requirements can be applied to achieve acceptable risk.
Cloud Services Public cloud IaaS and PaaS services can suggest a need for a set of
(infrastructure as a services, parallel standards, duplicating your data center approach.
service [IaaS], private cloud Instead, look to provide a consistent baseline by leveraging
platform as a services other domains (server, account management, databases). Add
service [PaaS]) clauses if specific requirements for IaaS or PaaS are
indicated.
Databases SQL and no- A single database standard will usually suffice although
SQL servers specific platforms may need detailed procedures.
Remote Access End-user VPN, Different scenarios for remote access requirements usually
third-party condense into these two scenarios, supporting two standards.
access
User Devices Corporate Defines the controls for endpoints, such as full disk
laptops and encryption, host firewall/IPS, user configuration, software.
desktops, BYOD introduces specific problems because the standard may
bring-your- not be achievable or enforceable. Consider using a BYOD
own-device policy to make statements about acceptable use and
(BYOD) conditions of use.
equivalents
Device
Group/Domain Notes
Examples
Storage Systems NAS storage, Storage approaches bring many scenarios, such as VLANs
file shares and, multitier solutions. Typically, clients focus on user-level
file-share security, and delegate other needs to architecture
areas such as network security.
User Account Active Active Directory security should be a standard all by itself.
Management Directory, Focus here on the requirements for account provisioning,
LDAP systems change management and object/account removal.
Source: Gartner (May 2019)
The important thing to note from Table 1 is that the grouping of your infrastructure systems is as
much an art as a science. Within any group of device types, there are fundamental differences that
may make it difficult to write a “one size fits all” security standard. This is not a problem. You can
reflect these differences through specific exceptions, or even subclassify assets using some
measure of value or risk.
However, try to avoid creating too many groups. This may lead to a library of standards documents
and complex requirements that can be difficult to maintain, since they are very technology-specific.
Security Controls
The alternative to technology domains is to focus on the controls potentially required. Table 2 shows
some examples of how this approach can reduce the number of documents required. The approach
uses the idea that security controls, such as authentication, can be abstracted. Doing this allows a
logic based on data classification and context to be used to specify when and what version of that
control should be used.
Note that the controls listed in Table 2 can also be seen in the security
groups shown in Figure 3 of “Building the Foundations for Effective Security
Hygiene.” Other control lists and groupings can be found in frameworks such
as NIST 800-53 or ISO 27002.
Each group can contain a large variety of technical and process controls that need setting at a level
appropriate for the organization. Try to avoid aggregating controls from different groups in a single
standard. For example, when writing an authentication standard, use use cases and classification to
create a single standard that dictates when each authentication technology should be used. That
same standard might be used to specify minimum criteria for the approaches, such as password
length, complexity and handling. Alternatively, a password specification (part of the
procedure/process family) can be used to determine this in much more detail.
This example highlights another issue, namely, that security technologies and best practices are
continuously evolving. In authentication, there are the concepts of “passwordless authentication” and
protecting passwords more securely. Precluding innovative security approaches that might better fit
the organizational use case is not the objective of security governance. This is where the use of risk
assessment, cyclic standards review, and exception processes to determine the acceptability of an
approach is so important.
Table 2: Security Controls Approach
Control Application Notes
Authentication Defines minimum Include a variety of controls such as passwords and

requirements for multifactor authentication (MFA), as well as defining
authenticating users which authentication infrastructures should be used and
based on data when. For example, all SaaS usage should be
classification and context authenticated via the corporate CASB leveraging the
corporate MFA solution.
Cryptography Defines minimum Defines when cryptography should be used. May also
requirements for using set minimum requirements for cryptography, such as
encryption based on data key length, storage, hash type and which public key
classification and context infrastructure (PKI) certificate authority must/must not
be used.
Network Defines the minimum If network segmentation is used to group systems or

Compartment requirements for applications, define the security of a segment based on
protecting a network the data classification. Each segment can then be
based on data labelled with trust level. Each compartment type will
classification and context have an associated set of control requirements.
Anti-malware Defines the minimum Covers endpoint, email, web gateway, etc. Specific
requirements for anti- implementation requirements might be put in a process
malware controls for all or architecture document.
environments
Control Application Notes
Log Defines the minimum Servers, applications and devices will all need to comply
Management requirements for log if they fit a use case. This may specify minimum log
and management, event entries, retention time, and the log management system
Monitoring monitoring and related or security information and event management (SIEM)
incident response based system to be used.
on data classification and
context
Account Defines how user and Must also address the use of root and other “generic”
Management service/application and privileged accounts.
accounts should be
managed through the life
cycle.
Patching and Defines how patches May also address vulnerability scanning requirements,
Vulnerability should be assessed and and how nonpatchable vulnerabilities should be
Management prioritized, along with addressed, including when risk exceptions may be
maximum allowed period required.
for application.
Web Gateway Defines how a web May also address when and what types of traffic should
gateway (or proxy) should be routed through such a gateway.
be used, and the controls
it should apply.
Email and Defines minimum Will also specify the control instance to be used. Use
Email requirements for email process documents to define how things should be
Gateway gateway security to implemented.
address malware and
phishing threats, spam
and mailbox security.
Table 2 reduces the number of the documents required at the standards level. But it highlights that
the approach can easily fail to provide solution architects with enough clarity. Technical architects
outside of the security domain should not be assumed to be experts in security controls. The reality
is that some technical domains such databases, SaaS, IaaS and third-party access, do require their
own standardized approach to security due to the inherent complexity in that domain.
A Hybrid Approach Provides the Best Outcome
Neither of the above approaches is enough, but combining them leads to a positive outcome. Some
security controls are “universal” in that they apply to all technology domains. These include
authentication, user accounts, log management, patching and vulnerabilities, anti-malware and
encryption. Others are so closely tied to a technology that the technical domain makes more sense —
for example, databases, cloud services, gateways and networks.
The approaches have a common theme: At some point, both will use risk to
determine what controls are required, or to group systems together in some
way. The difference between them is how you carve up the problem, not how
you decide the controls.
A solution architect looking for security requirements for a database containing sensitive information
might need to look at:
■ Authentication security standard (control)
■ Log management specification (domain)
■ Cryptography security standard (control)
■ Database security standard (domain)
■ Network security standard (control or domain, depending on approach)
Whereas, an architect looking to design a solution for third-party access to an application may look
at:
■ Authentication security standard (control)
■ Remote access security standard (domain)
■ Network security standard (control or domain)
■ Gateway specification (domain)
■ Cryptography security standard (control)
You will need to define your domains, irrespective of your approach, to suit your own technical
environment and risk approach. Start with the ubiquitous security controls, and then review what part
of your enterprise architecture needs domain-specific support.
Define Minimum Controls

At this point, you will have at least a core set of domains and security controls you want to address.
That list will change and evolve over time. The question is now how to decide what content should be
in the standards documents. What are the minimum standards that should be set to address the
identified risks successfully?
Prioritizing this work is important. It’s unlikely, unless there’s a significant team involved, that all or
even most of the requirements can be addressed simultaneously. If you have specific “hot spots” that
need urgent attention, prioritize these.
Everything else being equal, prioritize the security controls approach over the
technical domains. They cover a wider variety of scenarios, may provide
greater return for your time, and make defining the controls for a technical
domain easier.
What the required control is will depend on a risk assessment, your enterprise architecture and the
regulatory environment. But the control level may vary depending on the specific use case.
The key to codifying this in usable security governance, is in understanding the data that the solution
will be processing (see Figure 4), specifically:
1. Sensitivity
2. Criticality
3. The context in which the processing is happening
Figure 4. Repeatable Security Assessment
Understanding the relative value of your data assets and applying a categorization to them allows
appropriate security to be applied — matching controls to the risk. Remember that any decision will
be constrained by external drivers (e.g., compliance requirements) and influenced by best practice.
Please see the recommended reading section for links to Gartner research on data classification
policy.
Processing context can refer to a variety of factors. These may include networks, systems, cloud or
third-party processing. Look to focus on levels of trust in the environment and categorize many
actual use cases with similar levels of trust into groups. This will reduce the number of possibilities
to a manageable number.
Controls That Don’t Follow This Approach
There are some control requirements that don’t follow this rule. Typically, these are more “universal”
in their application and don’t depend on the data processing use case as much, if at all. The first
example below (encryption) highlights this point. Encryption requires a choice of protocols, key
length and other factors that set your cryptography usage to a safe level. These architectural
standards can be documented in the security standard document as a separate section or codicil to
the context-based approach for control application.
Identifying these details requires an understanding of the control being selected. Within the area of
network firewalls, for example, you may want to prohibit the use of certain protocols such as peer-to-
peer file sharing. That concept requires an understanding of how protocols may be used, and what
problems they might cause. Work with your security architects to identify these details and agree the
best approach.
In all the following examples, the control statements are illustrative only.
Your choices should be determined based on a risk assessment for the
organization
Example: Encryption on the Network
For example, you could categorize networks into four levels of trust (these labels are only examples):
internal enclave (highest trust); internal; transit; and internet (lowest trust). Trust here may be
considered as being equivalent to “exposure.” There may be multiple and independent examples of
each type that your organization uses and various network technologies in play. This doesn’t matter
because we are talking trust, rather than technology. For example:
■ Internal Enclave:
■ PCI DSS network.
■ Mainframe secure network.
■ Internal:
■ Any permanent network controlled at all perimeter points by your organization with no direct
interface to the internet.
■ You may consider IaaS “network” as internal if you have sufficient perimeter control equivalents
in place and you have sufficient trust in your service provider. You may also wish to separate
IaaS environments into a different category entirely depending on how they are structured and
managed (see Note 1).
■ Transit:
■ DMZ networks.
■ Any network with a direct connection to the internet.
■ Temporary remote access networks supporting user access.
■ Wide-area network connections, such as site-to-site and site-to-cloud, that connect networks the
organization controls.
■ Wireless networks operated by the organization.
■ Internet
■ Any network not directly and completely controlled by the organization, including publicly
accessible networks and B2B networks connecting with a third party.
At this point, we can combine networks and data classification into a matrix of security
requirements. Table 3 gives an example that might form the basis of the “data in motion” component
of an encryption standard.
Table 3: Data in Motion Encryption Security Matrix
Data Classification
Secret Confidential Internal Public
Network Internal Data must Data may be Data may be Data may
Trust Enclave be unencrypted while unencrypted on be
Level encrypted within the enclave if enclave and unencrypted
on all regulations allow internal networks on all
networks networks
Network Internal Data must Data may be Data may be Data may
Trust be unencrypted while unencrypted on be
Level encrypted within the enclave if enclave and unencrypted
on all regulations allow internal networks on all
networks networks
Data Classification
Network Transit Data must Data must be Data must be Data may
Trust be encrypted on internal, encrypted on be
Level encrypted transit and internet transit and internet unencrypted
on all networks networks on all
networks networks
Network Internet Data must Data must be Data must be Data may
Trust be encrypted on internal, encrypted on be
Level encrypted transit and internet transit and internet unencrypted
on all networks networks on all
networks networks
This highly simplified model doesn’t mention other requirements that may be important. For example,
you may specifically want all internet web servers to enforce Transport Layer Security (TLS) usage
for all traffic irrespective of its sensitivity. This would provide integrity and trust in the organization’s
public presence. You must consider use cases of this nature, that don’t fall under the
“classification/context” logic, as part of your controls selection process.
This matrix deliberately doesn’t go into detail of how, where and who should implement the
encryption. Data-in-motion encryption can be performed in various ways, including encrypted files,
session encryption or tunneling.
Example: Server Security
This example shows a matrix for securing systems based on their network location and system
classification. In the notes to Table 4, we also give examples of how exceptions may be considered.
Table 4: Server Security Matrix
Server Classification
Network Internal Servers must Servers must Servers must Servers must
Trust Enclave achieve the achieve the achieve the achieve the
Level “high” “medium” “standard” “standard”
hardening hardening hardening hardening
specification specification specification specification**
Server Classification
Network Internal Servers must Servers must Servers must Servers must
Trust achieve the achieve the achieve the achieve the
Level “high” “high” hardening “standard” “standard”
hardening specification hardening hardening
specification specification specification**
Network Transit Servers Servers Servers Servers must

Trust classified classified classified achieve the
Level “secret” may “confidential” “standard” may “standard”
not be located may not be not be located hardening
on these located on these on these specification**
networks networks* networks*
Network Internet*** Servers Servers Servers

Trust classified classified classified
Level “secret” may “confidential” “standard” may
not be located may not be not be located
on these located on these on these
networks networks* networks*
*Exceptions may be granted for specific projects. In this case, the “high” hardening specification and all
data-in-motion encryption requirements must be achieved, in addition to any specific controls necessary
under the terms of the exception.**Any corporate-owned servers should be placed on corporate-managed
networks where possible.***Third-party-managed systems processing corporate data on noncorporate
networks must achieve these same standards. Leveraged (multitenant) environments on noncorporate
networks should be risk-assessed, and specific exceptions and/or control requirements specified.
Table 4 introduces the concept of system classification. Data classification

alone typically applies to individual data elements — an email, file, folder or
database field. But most systems, such as an ERP, HR or CRM database,
contain a variety of data with different classification levels. Unless you can
assure the necessary separation to protect data of different classifications
within a system, classify it according to the highest data level it might
contain.
Example: Network Layer Authentication
Authentication is used for networks, systems and applications. When applying to networks, three
factors must be taken into consideration: source, destination and classification. Essentially, you need
to consider authenticating both at the network layer and at the system:
■ Source: The network type where the individual or system doing the accessing is located
■ Destination: The network type where the accessed system or application is located
■ Classification: The sensitivity of the system or application being accessed, based on the data it
processes
Typically, the logic behind this approach is to require more authentication when:
■ Accessing any system from a lower trust environment than where the target system is located
■ Accessing systems of higher classification
Defining precisely what level of authentication is required is, again, the output of a risk assessment.
But how the generic logic is applied is given in the example in Tables 5 and 6, which continue to use
the illustrative assumptions of the previous examples.
Table 5: Network Layer Authentication
Destination Network
Internal Enclave Internal Transit Internet
Source Internal Multifactor No specific No specific No specific

Network authentication for authentication authentication authentication
all individual required required required
access System System System
B2B or system-to- authentication authentication authentication
system access may still be may still be may still be
according to the required* required* required
specific
requirements of
the enclave
instance
Destination Network

specific
requirements of
the enclave
instance

specific
requirements of
the enclave
instance
Source Internal No direct access Multifactor Multifactor No specific

Network Enclave permitted for authentication authentication authentication
individuals. required for required for required
B2B or system-to- individuals individuals System
system access B2B or system- B2B or system authentication
according to the level access level access may still be
specific through through required
requirements of approved IPsec approved IPsec
the enclave or TLS or TLS
instance communication communication
only only
Destination Network
Source Internet No direct access No direct access Multifactor No specific

Network permitted for permitted for authentication authentication
individuals or individuals or required for required
system/B2B system/B2B individuals System
access access B2B or system authentication
level access may still be
through required
approved IPsec
or TLS
communication
only
*Two network compartments of the same type may require authentication between them for other reasons,
such as regulatory separation requirements.Note: Authentication requirements between two networks of
the same classification shall be as stated here or according to the specific requirements of the destination
network instance, whichever is the more strenuous. All communication between networks must be
encrypted according to the requirements of the encryption standard. This ensures appropriate tunnels or
session layer encryption is in place to protect the destination and source networks.
Table 5 focuses on network layer authentication. The “transit” network creates some interesting
issues because it groups several different functional network types together (wireless, remote
access and DMZ). Separating this group out into these network types is perfectly acceptable and
depends on how you structure and consider the risk of these networks. For example:
■ Wireless:
■ Always require multifactor authentication to wireless networks that connect directly to your
internal network, irrespective of the source destination, as they are a broadcast network with no
effective physical controls.
■ Require no or weaker authentication to the wireless network if it connects only to the internet
(subject to legal approval). Instead, require users to use their normal remote access system to
connect, treating wireless as internet.
■ DMZ:
■ Only allow connection to applications/systems located in the DMZ. Network layer access is
restricted to privileged users accessing from an internal network via a jump system.
■ Remote access:
■ Require multifactor authentication for all forms of remote access. Restrict remote access
“landing point” to a dedicated network and control further access from there.
Similarly, you may choose to separate out “internal” networks if you have specific instances that
require additional control. You may find the approach taken in the notes to Table 5 preferable, as it
simplifies the standard and delegates some decisions to architecture.
Example: System and Application Authentication
In Table 6, we show a similar logic, but for systems and applications. It also shows differentiation
between “user” read access and “user” write access.
Table 6: System and Application Authentication
Destination System/Application Classification
Source Internal Multifactor Standard user Standard user Read — no

Network Enclave authentication authentication authentication authentication
required Write —
multifactor
authentication
required
Source Internal Multifactor Standard user Standard user Read — no

Network authentication authentication authentication authentication
required Write —
multifactor
authentication
required
Source Transit No access to Standard user Standard user Read — no

Network secret systems or authentication authentication authentication
applications Write —
allowed from multifactor
transit networks authentication
required
Destination System/Application Classification
Source Internet No access to Multifactor Standard user Read — no

Network secret systems or authentication authentication authentication
applications must be used Write —
allowed from multifactor
internet authentication
required
Note: Reflecting the importance of maintaining data integrity for public-facing information of all sorts.
Standard user authentication must be compliant with the authentication standard. Local authentication is
prohibited for all access unless approved by exception.
Note that all these examples make a positive assertion about all known use cases. This is important
to eliminate any ambiguity. But it’s not always possible to identify all use cases in advance.
Therefore, you must apply a catch-all statement, equivalent to a “default deny” statement in a firewall
rule chain.
Such as statement might read, “Any situation not covered by this standard must meet the minimum
requirements for that data or system classification. It must then undergo a risk assessment to
determine if additional controls are required.” You may also want to require a risk assessment for any
scenario processing more sensitive information than previously considered.
This approach ensures that previously unknown external drivers are recognized and that new
technology is properly assessed for its ability to protect more sensitive scenarios. This approach
provides a safety net for all scenarios, with a higher level of safety for those with more sensitive data.
Defining how to do things is not usually the job of the standard. Instead, it falls under processes and
procedures. But there are circumstances where it’s appropriate to put this kind of information into the
standard. We provide one more example here illustrating how authentication can be more detailed
(see Table 7).
You could include these detailed requirements in your standards but separate them out so that the
details are in a separate document. The choice between approaches depends on personal taste, the
size of a combined document, and how your systems are built and used. In the next example, we do
this in the form of an authentication infrastructure standard.
Only document a control requirement or its implementation requirements

once in your standards documents. The more times it’s repeated across
different documents, the greater the risk of inconsistency and ambiguity, and
the harder it is to implement changes across the portfolio of standards
documents.
Example: Authentication Infrastructure Standard
Table 7: Authentication Infrastructure Standard
Authentication
Solution Options Notes
Method
Standard Corporate Active Procurement and design of systems requiring

Authentication Directory (Mandated for standard authentication should require this
all scenarios) capability as a must-have in RFPs and design
specifications.*
Multifactor Corporate MFA solution The use of multiple MFA solutions is not precluded
Authentication (mandated for all and may be required to maintain compliance. For
scenarios except as example, an external facing website supporting
defined below) customer access to finance accounts may require
IT MFA solution the use of all three prescribed solutions.
(mandated for scenarios
additionally requiring
compliance with the
privileged access
management standard)
Customer MFA solution
(mandated for scenarios
where corporate
customers are accessing
personal or otherwise
sensitive data)
Cloud Corporate CASB solution This solution leverages the corporate Active
Authentication to be used for all SaaS Directory and supports the corporate MFA solution
cloud environments for those use cases requiring it.
Authentication
Solution Options Notes
Method
Local Local authentication for Root/administrator accounts and equivalent should

Authentication interactive accounts is only be accessed in compliance with the privileged
prohibited except by access management standard.
exception
Service accounts may
use local authentication
on systems unable to
reference the corporate
active directory
All Other No other authentication Exceptions may be granted based on a risk

Authentication infrastructure is approved assessment and demonstration of inability to use
Solutions for use preapproved solutions
*Exception process: Exceptions to this requirement will only be granted where COTS or custom solutions
are unable to achieve the mandated option.
Table 7 shows how authentication solutions can be mandated or prohibited for use and expand the
requirements of the classification/context logic illustrated previously. It is an approach equally suited
for encryption, firewall rules, anti-malware and other controls that may be solved in various ways.
This approach achieves several positive outcomes:
■ Provides a strong link between security standards and security architecture.
■ Limits the use of authentication infrastructures to those previously assessed and approved by the
security team.
■ Limits the use of such systems to those supported by IT, at known cost, security and availability
levels.
■ Reduces development, deployment and maintenance costs by requiring well-known and reusable
approaches.
■ Reduces audit and other process demands to provide ongoing assurance for new authentication
infrastructures.
Mandate Standard Solutions
Standards specify the minimum control standard levels — they do not usually specify how they
should be achieved, although it is acceptable to do so. Doing so is subject to several factors, such as:
■ The rate of change (remembering that each change needs formal approval at this level of
governance)
■ The detail required (more detail may affect the readability)
■ Availability of alternative documentation opportunities, such as architecture or specifications
The authentication infrastructure example (above) highlights a standard requiring the use of a
standard solution, not just a minimum level of control.
It is usually advantageous to define a standard approach, such as an approved service or process, to

meet control requirements. Requiring architects to reuse or leverage standard solutions should be
your preferred approach where possible because it:
■ Reduces the variety of outcomes
■ Helps drive consistent quality and reliability
■ Reduces costs (in the longer term at least), through scale, buying power and reduced reinvention
■ Supports centralized monitoring, and any security processes to react accordingly
■ Assists the security team by introducing standardization into the environment
■ Supports management by exception based on noncompliance with a prescriptive method, and

supports a variety of compliance measurement initiatives
Typical examples of standard solution mandates include:
■ That application developers be required to use a pre-existing authentication schema, such as

Active Directory, rather than local authentication within a database, a UNIX/Windows server or
their own created solution.
■ Digital certificates be obtained from a corporate PKI or approved service — self-signed certificates
are proscribed outside of the development environment.
■ Anti-malware must use the corporate approved anti-malware solution for the device being
protected.
However, it’s not always pragmatic to demand such approaches in the short term. For example,
budget issues can preclude short-term expenditure in building the solution to be used. Longer term,
transition costs can delay takeup. Enterprise architecture change can create opportunities. For
example, a migration to a SaaS environment can create an opportunity to implement a CASB and
multifactor authentication solution, which can then be mandated for other solutions.
To address this, you may elect to provide staged options for technical professionals. For example:
■ Where a central (IT- or security-provided) solution exists that is compatible with the system being
secured, this solution must be used.
■ If, due to technical incompatibility, this cannot be used, then a dedicated solution, approved by
both IT and security, may be used.
■ Such a dedicated solution must be removed and replaced by the central solution when and if a
compatible one becomes available.
This provides flexibility, while retaining the appropriate level of control and risk management.
Standardized Processes and Procedures
Processes and procedures mandate that something be implemented in a specific way. These
mandatory documents specify how the requirements in the standard must be achieved. For example,
a server standard may require that a specific approach to hardening some systems is taken. The
process for hardening would be documented in a specific server-hardening specification (e.g., a UNIX
security specification or Windows security specification). The detailed content and format of these
documents is out of scope for this research, but they are typically:
■ Written by technical domain experts rather than security as part of a security architecture process
■ Subject to relatively frequent changes, both as technology use changes within the organization
and as vendors develop their systems
■ Detailed steps and/or configuration items that may be subject to scripting, imaging and automated
ongoing checks for compliance
■ May use public (e.g., the CIS Benchmarks) or vendor baselines, possibly without change
Procedure documents must be maintained as part of security governance and subject to a change
and review process. But approval may only be required by the technical domain manager, rather than
security or risk teams. This implies a level of trust that the procedure complies with the relevant
standards. Test this with occasional reviews, often most easily done as part of any review of a
relevant standard.
As an example:
■ The database security standard might say:
■ If available, use built-in database encryption, such as Transparent Data Encryption (TDE).
■ Otherwise, use an alternative data-at-rest encryption solution.
■ Security architecture patterns or security procedures will then say:
■ TDE must be implemented using the following configurations.
■ If TDE is not available for the platform, use the following technology, as implemented by IT
security.
If there is a security architecture function available, be certain to use it to

provide guidance and review, but especially to own these lower-detail
documents. Security architects have unique insight into the needs of
enterprise and application architecture teams, as well as business
requirements.
The Future
The examples above show how data classification and context can be used to define minimum
control requirements in a clear and logical fashion. They also show how the IT architecture can be
used in parallel to define control requirements (see Table 5). Finally, it shows how these logical
approaches need supplementing by specifying how those minimum requirements should be
achieved (see Table 7). In combination, these show how the hybrid approach discussed in Identify
the Domains for Coverage section can be used to provide robust, coherent and integrated set of
control requirements.
But security controls must always evolve. As things change, controls fluctuate in importance. This
must be reflected in your security standards. The Governance section below shows how to build a
continuous process for standards review. But that is not enough. The controls you select today need
to reflect a continuously changing world. This is important to protect and inform both security and
other architects within your organization. They need to be able to build to a plan, rather than
continually reacting to changing control requirements. You need to build some form of roadmap.
To do this, review all controls that are in place in your environment, and if mandated or
recommended, comment on the “when.” It’s always a good idea to explain your statements. For
example:
■ The use of XYZ product is deprecated and must be replaced by the official corporate solution by
<date>.
■ XYZ has been found to be incapable of supporting our “cloud first” environment, and this expiry
date is in alignment with enterprise plans to complete migration to the cloud.
■ From <date>, the use of ABC encryption protocol is prohibited. All new deployments must use
<alternative> with immediate effect. All existing deployments of ABC must register with
information security and develop achievable plans to migrate or request formal exception.
■ ABC encryption has known vulnerabilities that have been found to materially impact our
business risk.
The next stage is to document the requirements in a way that is useful to the intended audience and
supports ongoing governance. At this point, the control tables are not useful; instead, expansion and
commentary are required. Now it is time to write and publish the standards as official governance.
Do not wait until a full set of controls has been defined to write and publish
standards. These will be living documents under continuous review, and it’s
usually more important to publish governance quickly than to wait for a full
set.
Write Standards
Draft Documents to Reflect Control Requirements
As you develop your control requirements, you will need to start writing the standards documents
themselves. Defining minimum controls should be concurrent with writing standards. When writing
governance documents, the following principles should be applied.
The Audience Is Important
As described in the introduction, this research discusses standards, and to an extent, processes and
procedures. The line between a policy and a standard is blurred, and any distinction will always have
exceptions. Here, we use the intended audience to define the difference:
■ Policies are intended for all workers in an organization, irrespective of their role or contractual
status.
■ Standards and guidelines are intended for those who build, operate or contract tools or services
that may introduce security risk that must be addressed.
The recommended reading section contains references to Gartner research on writing policies. But
there are some key concepts normally included that enable integrity of governance. These include:
■ Making users aware of their day-to-day responsibilities to protect data, the company, clients and
colleagues.
■ Giving users a clear understanding of how the organization views data confidentiality, and how
they should judge the sensitivity of any piece of information.
■ Informing users of the basic procedures they should follow given a specific circumstance, such as
requiring access to a system or application.
These are security-specific concepts that guide users in their day-to-day activities and should be
considered a minimum for security policy. But writing for the general user is a different challenge
than writing for technical professionals. Policies must be accessible to all members of the
workforce. Thus, it is important not to overload policy documents with detailed technical
requirements.
The audience for security standards is the technical professional tasked with architecting,
implementing or operating some form of technology to support a business process. As such, the
standards can, and should, be written in more detail to make sure they provide the necessary level of
information to this audience.
For example, when reviewing client documents, we often see security documents such as a broad
“security policy,” or an “acceptable use policy.” Often, these documents attempt to be all things to all
audiences. They are long and use a mix of language targeted both at the general user and the
technical professional. Describing how laptops should not be left visible in parked cars contrasts
greatly with detailed information on the types of encryption to be used or the configuration of Active
Directory. Mixing the two audiences can often result in documents and requirements being
misunderstood or not even read.
Write your security governance documents with the audience in mind.

Separate information and requirements appropriately to ensure clarity and
relevance.
Use a Standard Template
Using a standard template for your documents makes reading your security requirements much
easier. An example template (please modify to meet your own requirements) is given as part of this
research as an attachment.
Imperative and Discretionary
Security controls are either mandatory or optional. Select terms that ensure that it is clear which
requirements fall into which category. Use imperative words (and their local language equivalent) for
mandatory controls and more discretionary words for optional ones. Examples are:
■ Imperative: Will, must, shall, must, shall not, must not
■ Discretionary: Should, should not, can, may
You must (imperative!) use the appropriate language when writing security standards and policies to
ensure that controls are applied as expected. You may (discretionary!) ignore this advice, but it can
lead to problems. For example, implementations that introduce unacceptable risk the standard allow
architects to make choices that may be inappropriate. You can use discretionary terms where you
see fit, but the decision you make should be considered. For example:
“All servers storing or processing sensitive or higher classification data must use the privileged access
management service for all administrator access to the OS, database or application. Other systems
may use this service if required, based on the outcome of a risk assessment.”
In this example, the required and optional outcomes are clearly distinguished and allow for no
ambiguity for the technical professional implementing or designing a solution.
The IETF RFC 2119 contains more information on this topic and may be found at: “Key Words for
Use in RFCs to Indicate Requirement Levels.”
Separate Control Requirements and Discussion
The security standard can be kept very simple by listing only which controls should be used and
when, or what is allowed or prohibited. However, technical professionals looking to understand
security requirements may find it helpful if there is also some discussion about why the controls are
important or were selected. A solution architect having problems complying with your standard can
benefit from the additional insight. Exception requests can be better positioned or even avoided if the
developer can use such explanation to explore alternatives.
But do not clutter the document with too much history or background information. It’s easy to hide
the important information inside such discussions. This should be avoided. Keep the following in
mind:
■ Organize your standards template so that discussions and footnotes are below the control
requirements.
■ Avoid putting requirements in the discussion section where they may be missed.
■ Keep requirements relevant to the standard at hand where possible. To avoid proliferation of small
documents, insert an “additional control requirements” section if necessary.
Personnel and situations change, and it’s easy to lose the organizational memory of why a process or
standard is the way it is. The discussion can provide continuity in the ongoing governance and
maintenance of the standards, acting as a reminder of why something was decided.
Minimum Information (Metadata) Requirements
Security standards are subject to formal change and review processes (see the Governance section
below). Documents should be consistent in format, although precisely what that means will depend
on the organization’s own preferences. Besides the control requirements, the documents should also
contain consistent information about the document itself, providing it with the necessary authority.
We list these minimum requirements Table 8.
Technical professionals reading the document do not need to know what the last five years of
changes have been. They need to know what they must comply with today. But you should keep older
information somewhere because it forms a part of the review process, exceptions process and risk-
management understanding.
Table 8: Document Sections List
Information Notes
Title Title must clearly and specifically indicate the standards coverage area.
Effective Date Date when the standard became part of governance. This may be the same as the
date the document was formally approved or published. That depends on the
organization’s own governance policy.
Version Number Allows tracking of copies to ensure older versions are identifiable even if their “next
scheduled review date” has not yet been reached.
Information Notes
Next Scheduled Standards should be regularly reviewed according to a schedule. (See the Governance
Review Date section for more details.)
Reference If you have a broad set of governance documents, the reference number uniquely
Number identifies this document and becomes useful in indexing and organizing governance
storage.
Approved By The approver must be someone with the appropriate authority to enable the
document to be considered as authoritative within the organization. Being an
approver does not imply that the individual owns the risk being addressed. This may
be the case for policies, but not for standards. A single standard typically only
partially addresses multiple risks through a single set of controls. The entirety of a
project or other risk needs multiple standards for sufficient mitigation. The approver
here owns the document and accepts that the controls within it are acceptable within
their domain.
Written By This can be a team, role or individual. It indicates ownership of the content, and
where the domain expertise lies for any questions relating to the content and intent.
Introduction What is this standard addressing, and why? For example, “This standard addresses
the minimum-security requirements for all corporate-owned and-managed networks
to protect against unauthorized access, data leakage and malware attacks.”
Scope of To which parts of the organization and/or the technology does the standard apply?
Applicability On the face of it, a standard may apply to the whole organization. However, there may
be parts that have a different governance structure for this control issue, for example,
a wholly owned subsidiary, a business unit in a different region, or a business
operation subject to different regulations or contractual obligations. Comment on
where readers should look for the alternative governance.
Control Describe the control statements determined to be necessary for this standard. Use a
Statements clear, sectioned approach to aid readability. Tables can help clarify decision making
for readers. Limit content in this section to the actual control requirements and avoid
using it to provide supplementary information or background insight.
Roles and Describe who is authorized to make decisions relevant to this standard. Which
Responsibilities organizations are authorized to provide services delivering any of the required
controls under this standard?
Information Notes
Compliance If relevant, describe what the solution architect must do to enable and support
Monitoring compliance monitoring. This may include configuration, access permissions,
reporting through an automated system such as console output, or manual reporting.
Define the period and type of information required, and where that information should
be sent or otherwise made available.
Background If necessary and pertinent to people implementing controls or solutions requiring

Information controls. Use this section to provide discussion about how the controls affect risk,
specific use cases that might require additional controls, and to expand on the
objectives or possible future direction of the control requirements.
Other Relevant List other documents the reader may need to be aware of, such as other closely
Documents related standards or process/procedure/specification documents. Include (if directly
relevant) nonsecurity documents, such as IT policy/process or procurement, external
references such as vendor documentation, or public standards documents such as
NIST or ISO. Describe how these documents should be treated in the context of this
standard. External references should always be described as “background” that in no
way supersede or replace the control requirements stated by internal standards.
Contact Points List any relevant contact points for questions, clarifications or implementation
issues. This might include security, IT or other teams who are responsible for the
document contents or providing/supporting specific controls and control instances
required within the document. This section should always contain reference to the
entry point for the exceptions process.
Consequences Insert statements about the consequences of noncompliance. This typically includes
of references to the effect that noncompliance will be treated as a violation of the
Noncompliance organization’s disciplinary code. You may prefer to reference a specific policy-level
document (if one exists) that covers this issue rather than repeating information here.
Revision History Maintaining a brief revision history helps readers understand the background as well
as aiding in managing compliance issues.
Test Documents With Intended Audience

As discussed above in the Prework section, security standards can have a disruptive effect on IT,
applications and other teams both in the short and long term. The objective is to manage risk in such
a way that all stakeholders can be satisfied. Your new security standard needs to be tested with the
people it will affect. For an updated document and stakeholders who are used to such reviews, this
might be done through an email. But be prepared to spend a significant amount of time explaining,
discussing and responding to comments and questions.
Compromise, which can be the outcome of this process, must be handled with care.
Your control requirements are the result of risk assessment, not random
control selection. Any change to the level or type of control will have an
impact on the residual risk, perhaps in unexpected ways, and so should
require a high bar for acceptance. Substituting encryption types can help
with breach risk but may cause issues for data recovery.
However, it’s quite possible that initial assessments may have missed something that would change
the decision in either direction. Be open to the possibilities.
As with most things in security, objections to new controls can come in various forms — cost of
implementation, disruption to business process, limits to flexibility, change in common practice. It
may just be poor perception of the security issue. The last objection should be handled by the risk-
assessment approach we have described to this point, but occasionally this may be insufficient.
Risk assessment is not a perfect science. It’s not always possible to come to a “correct” answer
through risk management. Sometimes you will need to take a more pragmatic approach. One
organization was struggling with the high cost of password resets, driven by a very short password
life cycle and clustering of password changes around the end of the month. The outsourced help
desk was overrunning its budget monthly. By changing password complexity and length, and then
reducing the cycle time, password reset numbers plummeted, reducing business impact and cost,
while the security risk was maintained above minimum acceptable levels.
The implementation of the control can be more problematic. A new requirement to implement
encryption using a centralized service rather than self-signed certificates can drive significant
change, rearchitecting and design, introducing unplanned costs. Technical professionals faced with
such work may struggle to understand why their current solution has suddenly become
unacceptable, especially in the face of potentially onerous rework to achieve compliance. Business
leaders may balk at spending money for no apparent benefit, especially in the short term. In the
Implementation section below, we discuss the concept of grandfathering and compliance leeway.
But when building the standards and socializing them for acceptance, you must take a broader view
of the problem than “risk assessment means X.”
If you followed the prework and involved stakeholders in the process, then objections should be
limited, as you will have had the opportunity to factor them in already. These steps also allow you to
announce the changes that may be ahead, providing a lead time to enable architects to respond
appropriately. You may find that you are unable to overcome objections through arguments such as
compliance, risk management, standardization or cost, and need to make a change. In this case, be
sure to document very clearly what the change is, why, what the risk assessment indicates, and if
necessary, place it on your risk register. Review this as part of your standards review process (see the
Governance section) and your risk management process, and act when needed.
Note: The guidance framework is a meant as a continuous process. As discussed in “A Guidance

Framework for Establishing Your Approach to Security Architecture,” make your security standards
approach a living process, allowing and supporting intervention and change at all times. This flexibility
will, while properly governed, allow alignment with architecture teams and support the business
properly.
Remember, a change to a standard will affect many instances of a risk within the organization, not
just one project. Use an exceptions process to control this weakening effect if possible. A single
exception to one project for one requirement is better than weakening the whole organization by
standardizing a lesser control.
Build Exceptions Process

A few of the examples in the Determine Control Requirements section refer to exceptions. The
exceptions process is a critical part of security governance because it provides a controlled
approach to resolving issues where the specific requirements of the standards cannot be met. The
exceptions process allows developers to do something different while ensuring that the outcome
meets acceptable risk levels, can be supported properly and is properly documented. A single
exception to one project for one requirement is better than weakening the whole organization by
standardizing a lesser control.
Sometimes, exception requests may lead to changes in the documented governance. Examples
would include when they highlight repeated issues with existing requirements, or when an acceptable
and supportable alternative is identified that meets the strategic requirements of IT and the wider
organization.
Every security standard will at some point come up against a business or technical problem that, at
least in the short term, prevents compliance. Perhaps the necessary business functionality is only
provided by a commercial system that cannot comply with the encryption standard. Maybe a legacy
system cannot be upgraded or replaced in a short enough time that it can achieve your new
authentication and password standards. There will be a constant stream of such issues. It’s not
possible to require complete enforcement of your standards and still be perceived as supporting the
business.
Security standards are to some extent aspirational. One reason to have them
is to allow you to enforce a process of recording and approving
noncompliance and the risk that introduces. Draconian enforcement
requirements will break the business, the security team or both.
The importance of risk assessment as a basis for your standards has been highlighted in earlier
sections. The exceptions process — a formal way of requesting, assessing and approving individual
noncompliance — uses that risk assessment process to allow consistent response to point issues.
Granting an exception does not mean your security standard is wrong, although having to grant many
for a similar reason may suggest something is awry. It merely reflects the huge variety of IT and
application use cases that exist that can’t be fully predicted in governance.
Gartner provides research on building an exception process (see recommended reading section), and
you should reference that resource when building this process. Three things are required, which build
on the risk assessment process and your risk management framework:
■ A clear, documented flow chart showing entry and exit points, key decisions and responsibilities
assigned (see Figure 5, below)
■ A responsible, accountable, consulted and informed (RACI) chart (or equivalent) showing who has
what authority in the process
■ A method of recording decisions and revisiting granted exceptions on a periodic basis
Finally, the process should in itself be part of your formal security governance, approved by the
appropriate individuals in your organization, published and maintained.
Figure 5. Example Exception to Policy Process
Figure 5 shows an example of what an exceptions process might look like. Your organization may
vary in terms of the responsibilities, specific steps and decision points. You may have a different risk
structure than High, Medium and Low, and with different responsibilities the entry points and
approval points may also vary. What is important is that all the approval authorities are matched to
the risk level.
Conditions for Granting Exceptions
Exceptions that are granted without even a long-term plan for remediation back into compliance can
set an expectation of permanent approval. This should be the exception, rather than the rule. But if
that is the intention, it should initiate a review of the relevant security standards to see how they may
be adjusted to reflect that risk appetite.
An exception request should include:
■ A description of the problem
■ The standard requirements that cannot be met
■ An assessment of the risks it introduces
■ The planned workaround to manage that risk
■ The long-term plan for removing the risk

■ An expiration/reassessment date
Gartner recommends resisting approving exceptions that do not have both short-term mitigation (i.e.,
workaround) plans and long-term remediation plans to remove the risk.
The “end: exemption approved” part of this process is not the end of the risk, unless there is
significant change to the business activity and supporting technology. Therefore, something needs to
happen to manage the risk.
An approved exception to a standard accepts limited risk on a temporary

basis. But even an accepted risk is a risk: It must be recorded in the risk
register and periodically revisited. Do not approve exceptions without a time
limit for reassessment.
Use the risk management framework to drive periodic reviews of risks arising from exception
approvals. This allows a continual reassessment of these individual exceptions in the light of new
threats, vulnerabilities and other environmental and business changes.
Implementation
Everything is now set for gaining approval for your standard, releasing it to the wider organization,
and building a program for compliance. First, you need to have the appropriate management roles
approve the document.
Gain Approval and Publish

Once the standard has been accepted by peers and stakeholders, it needs to be implemented. This
requires:
■ Getting formal approval for it to become part of corporate governance
■ Publication and dissemination
■ User education and awareness
Different organizations will have different approval processes and levels of authority. Typically,
standards will be approved at the C-level rather than the board level. Confirm what is required in your
organization.
Approval should be a considered an exercise, not a rubber-stamping. The standards you write will
form part of mandated approaches to operating the company. Approval and adoption must be
handled with care. Arrange for a focused discussion with the approvers on what the standard
contains, why, and how you arrived at a risk-based consensus for the controls you’ve documented. Be
prepared to discuss business impact, compliance, and any significant investments or changes that
might be required to achieve the security standards you’re proposing. Achieving a consensus with
stakeholders should allow you to assure the approvers that your standard is the right direction for the
company.
Document your approval. Record the approvers, when approval was granted, any specific comments
or conditions, and when the next review is required.
Approvals are not permanent. Every document should have an expiry date that sets up the next
review and approval cycle. This helps to ensure standards are relevant and prevents orphaned
documents that were approved by individuals who have since moved on.
Publishing the standard involves making it easily accessible to all individuals within the organization.
As discussed previously, standards are targeted at technical professionals, not the general user. But
all corporate governance should be available to all users. Even though the target audience is specific,
responsibility for compliance lies with all individuals in the company.
How and where you publish depends on your corporate approach to internal communications.
Internal web or share-point sites are enough. Email is not suitable except to notify people. It doesn’t
guarantee availability, and especially excludes new starters. But once published, you need to notify
people that it’s there and in force. Send specific emails to the target audience. Take the opportunity
to leverage more general corporate emails and communication approaches to inform people in the
wider audience. Build references to your standards into your corporate user awareness campaign,
onboarding programs and any other relevant HR processes. Highlight the existence of the standards
within broader policy documents, such as an acceptable use policy.
Address the Pre-existing Environment

Your security standard will almost certainly have been published when IT, OT and applications
already exist within the organization. Some parts, perhaps the majority, of that pre-existing
environment may not meet the standards that are now required. This will not be a surprise. Because
you included the IT and applications teams in the development of the standard, how it relates to the
current estate should be well-understood.
There are several ways to address compliance in the pre-existing environment (see Table 9).
Table 9: Handling Compliance in the Pre-existing Environment
Status Approach Risk/Exception Notes
Status Approach Risk/Exception Notes
Compliant with new No action None required

standard required. relevant to the new
standard.
Noncompliant — Identify short- Put in place Long-term legacy environments

technically unable to and long-term exception approval can often struggle to be
comply approach to (if granted) and risk compliant with current security
mitigate, register, including requirements yet be so important
remediate or planned mitigation, to the business that they cannot
retire. remediation or be retired. Following the
retirement. exception process ensures due
diligence can be demonstrated,
even if the outcome is known in
advance.
Noncompliant — Review current Put in place “Grandfathering” previous risk

previous risk risk exception approval acceptances for new standards
acceptances in place acceptance, (if granted) and risk is acceptable as long as
identify any register, including appropriate review takes place to
gaps and planned mitigation, confirm relevancy and address
enter into remediation or gaps.
exception/risk retirement.
process.
Noncompliant — plans Review plans Provide exception Time is the main concern. A high-
to make compliance to ensure they approval based on risk situation with a two-year
exist, including lead to plans, record in risk remediation horizon is a bigger
retirement/replacement compliance. register and review concern than low risk, or one with
if appropriate at appropriate time. a short planning time. However,
the plans are likely to be the best
approach to remediation, and as
such, an exception approval is
normally the default.
Table 9 shows that there are various levels of noncompliance, ranging from “cannot ever comply” to
“will comply in a very short time frame.” Always follow the exception process to ensure that all
situations are properly reviewed and documented, allowing leadership to be made aware of the risk.
Compliance Reporting
Security standards set a minimum level of implementation quality. It’s necessary to measure this
quality so that decisions can be made about the standards, both compliance to them and the
resulting risk. Through the formal exception process, you will be measuring noncompliance where it
is reported — normally at a project level, rather than a more detailed per-system report. You will also
need to measure ongoing compliance, both to technical and procedural requirements. For example:
■ Ongoing, but transient, deviations from patching requirements
■ Coverage and currency of anti-malware controls
■ Performance of access authorization reviews
■ Location of highly sensitive data within approved environments
Reporting on these types of compliance should be as continuous as possible within the bounds of
ease of reporting, cost and the risk that drift from compliance introduces. In practice, this might
range from near real-time reporting (when a technology supports or provides such a dashboard), to a
quarterly manual report (when a manual process is being reported).
Compliance reporting is in most cases no more than measuring against a target, and its
effectiveness depends to some extent on the organization’s maturity in reporting and review
practices. The Gartner research document “Developing Operational Security Metrics” discusses the
creation, use and setting of metrics. Using scripts to test system configuration or built-in tools to
report on firewall rule status can test compliance for specific situations. However, sometimes
metrics are not enough, and for these situations, the use of an audit-based approach can be fruitful,
although stressful.
Penetration testing can be used to test compliance, but this is unusual — such tests are normally
used primarily to test security. The outcome of a penetration test activity may demonstrate that a
security issue arose because of noncompliance, but this is not the primary goal of such an activity.
“Using Penetration Testing and Red Teams to Assess and Improve Security” discusses these
activities in more detail, and further Gartner research is listed in the recommended reading section
below.
A productive compliance management approach is to embed security review in the projects

themselves. Use project kickoff to assess how the project requirements drive controls and then test
at stage-gates for compliance. Build an ongoing risk assessment process for developing and
implementing projects to measure compliance and identify changes to the vulnerability and threat
assessment.
Audit
Auditors will spend time reviewing all parts of an environment within a defined scope (including
process and technology). They will provide a report based both on compliance and their opinion of
the actual security and risk status of that scope. Internal audit can be used for this if auditors have
the requisite skills. Otherwise, you might engage an external provider. It is essential to work with
auditors beforehand to plan the scope, timing and objectives of the audit.
Moreover, it is crucial to be clear about the intent of the audit. Is it merely advisory, or will there be
stronger outcomes (perhaps a subsequent audit to test remediation)? The teams being audited must
be given time to prepare. They will need to understand the goals, scope and implications.
Expectations should be set with both auditors and auditees as to time, resources and commitment
levels. Try to build a relationship with the auditing team to facilitate ongoing and repeated planned
audits as part of the overall compliance testing and reporting process.
Governance
Everything is now in place. The standards have been published. Exception and remediation plans are
in place, and compliance reporting is giving status insights. The final piece of the puzzle is to
implement a governance process that ensures the standards are continuously reviewed and updated
so that they remain fit-for-purpose.
This is important because things change:
■ IT changes. Standards become irrelevant or unable to ensure effective controls are in place, for
example, when moving from a traditional server/app model to a cloud-based PaaS architecture.
■ Business changes may require different processes or need compliance with different regulations,
for example, when expanding business into a different market.
■ The threat environment changes, bringing up different risks. For example, new exploits for
vulnerabilities appear continuously, but sometimes there are step-change attack types, such as an
attack on encryption, that require a similarly significant change in defenses.
Each of these is addressed in the sections below.
Any changes in the standard will need to go through the approval and publication process, and may
impact pre-existing environments and compliance reporting as well. It is acceptable to require
potentially different levels of approval for major and minor changes, depending on the risk and
impact of the change.
For example, prohibiting the use of a cryptographic hash standard because of a recently discovered
vulnerability may have no impact if it’s not in wide use within the organization. But if it’s the de facto
standard of use, changing hashing implementation can have far-reaching effects in both applications
and certificate management. Such a change may need more senior levels of approval.
Continuous Review Cycle

The basic governance process is a continuous review cycle that provides a scheduled process for
reviewing all security standards and related documents. Perform scheduled reviews even if there’s
been an event-driven review. Event-driven reviews are likely to be specific and may only affect one
control within a standard that contains many.
Review standards annually, at a minimum, even if no changes are

anticipated. Standards reflect detailed technological issues that change
continuously. Any longer could expose the organization to greater risk than it
has appetite for.
As your portfolio of standards builds up, you will need to setup a rolling process through the year to
distribute the workload. The review process will need to include all the stakeholders involved in
building the standard in the first place.
Figure 6 shows an example cycle, with a four-month review/draft/publish period per standard. Four
months should be considered long for most reviews, especially after two or three cycles, when the
standards have stabilized and matured. But allowing sufficient time for review and any changes is
important. Do not shrink the review period to the point where effective review and discussion cannot
happen.
Using a quarterly approach can also work, but with large numbers of standards, key individuals may
be asked to work on several documents at once, placing unrealistic demands on resources.
Figure 6. Example Standards Review Cycle
Each standard should have an owner for its review cycle. The owner is responsible for making sure
the review goes through each of the steps appropriately, with documentation and due diligence. This
individual will normally also be responsible for drafting any necessary changes.
Monitor for Threats That Drive Review

Threats and vulnerabilities of all types change and appear frequently. A lot of the time, new threats,
such as a new piece of malware, are adequately met by existing security controls. Vulnerabilities
have the same characteristic — the patching program is a control that addresses new vulnerabilities.
However, sometimes something new appears that may not be addressed by the existing control
requirements.
With good monitoring programs, an organization may be lucky enough to detect a threat before it
becomes an issue. But it’s as likely that the problem may only be identified after an incident has been
analyzed.
Your standards were built based on risk assessment. A previously

unidentified threat creates a new risk that demands a new risk assessment.
If you’re reviewing because of an incident, then that risk has materialized
once and will happen again unless something changes in the organization.
Two things may require attention:
1. An incident may have been due to a compliance issue, not a gap in the control requirements. In
this case, look at the compliance reporting (metrics) to see if that failure could have been
identified early and remediated before the incident.
2. Your control requirements need modifying because there may be a gap. Do not perform a “knee
jerk” change — it might be urgent, but the impact of changing controls without due process can
have unintended consequences for the business.
■ Perform a measured review to identify the extent of the risk.
■ Identify possible controls that could mitigate it. Be sure to include processes, procedures and
architecture in the review. Maybe you need a simple configuration change in the Windows
Server build process rather than a major addition of a new access control element in the
standard.
■ Go back to the Write Standards section above to draft, test and build approval for these
changes.
Business- and IT-Change-Driven Review
As the business and its environment change and evolve, new business processes and supporting IT
will be introduced. These will introduce new risks that may not have been considered when drafting
your original standards. If you based your security requirements on data sensitivity, then you will
often find that these new environments are covered by the standards at least to some extent.
However, there will be times when a new approach needs a response. Some example scenarios are
given in Table 10.
Table 10: Example Business and IT Change Outcomes
Change Impact Outcome
Outsourcing a Low/High Impact varies with the data content of the process. It may
business process to a require a change in standards, especially the first time, and
third-party provider. may even require the development of vendor-specific
requirements to be embedded in contractual documents.
Win new contract Medium/High Potentially, customer requirements may change or exceed
with new customer. current security standards. Review the gap and determine
how to achieve the requirements. Specific standards for this
customer may be appropriate, if the processing context can
be sufficiently separated from the rest of the organization.
Change Impact Outcome
Move from Low Unlikely to require a change in standards, but procedures will
technology A to need updating accordingly.
technology B, no
change in business
process.
Outsourcing Low/Medium May require change in standards to cater for third-party

technology to a third- remote access, specific role-based access control (RBAC)
party provider. requirements, etc.
Existing procedures may need transferring to provider, or
sunsetting existing procedures and using contractual
commitments to allow provider to “do it their way” while
achieving security outcome KPIs.
Replicating Medium/High Will require change and possibly addition to standards and
technology in IaaS procedures to cater for new technology in new context. This
cloud. would include cloud workload protection (CWPP),
connectivity, IAM, encryption and cloud configuration
requirements.
May require new security technology (e.g., CWPP) to support
new environment.
Use of new High Will require additional standards because some controls will
technology in cloud, no longer be in the direct control of the organization, if
e.g., containers or available at all. Requiring a specific control in the underlying
something as-a virtualization layer if managed by a cloud provider may not be
service (PaaS, DBaaS, possible.
SaaS). Existing standards will need modifying to cater for the new
context — for example, when and what type of encryption
should be used in a PaaS environment.
Will require new procedures for configuration of new
environment.
May require new security technology (e.g., cloud access
security broker [CASB], CWPP, monitoring) to support new
environment.
The key to maintaining standards in new environments is early engagement. Being aware that there
are new plans for the enterprise architecture and having the time and opportunity to perform risk
assessments early will prevent many issues further on. Your risk management program should be
engaged closely enough with IT and applications teams to support this requirement.
Risks and Pitfalls

The benefit of following a logical approach to constructing security standards is that it provides
coherent set of requirements for the technical professionals in your organization. However, there are
some potential risks and pitfalls that the security professional should be aware of. We list the major
ones here, along with some approaches to mitigation.
Missing an Appropriate Control Strength

Setting a level of minimum controls is not easy, except for some of the more ubiquitous technologies
and processes. There will always be situations where you either end up setting controls that are too
weak or too strong. Both have implications for corporate risk management and cost management.
Use the standards committee, governance process, business and architecture teams, and standards
frameworks to reduce this risk as much as possible.
Policies Versus Standards

In the introduction, we presented a distinction between the different document types based on
audience. While differentiating documents is important for the reasons given, if made too complex
and the audience is not clear, it can degrade the impact.
Be sure to label documents correctly, including the intended audience (e.g., “all users,” “technical
staff delivering X”), the type of document and where it sits in your policy framework. Write a short
note explaining the framework and how documents fit together. Use language appropriate to the
audience — technical for standards, more generic for users.
Large Document Sets

You may, over time, end up with a pile of documents. Gartner has seen clients with huge numbers of
security governance documents, even approaching 100 or more. The reality is that navigating,
complying and maintaining such a wide governance set is hard if not impossible, leading to security
risk, outdated documents and incidents. There is no single right number, but always working to
simplify and reduce is important to reduce the impact of documents exceeding their “use by” date.
Keep standards fewer in number with broad control requirements. Prioritize common and high-risk
requirements, and place lesser issues within existing standards if there’s a logical place to do so.
Remember that security has relatively few families of controls, so it isn’t necessary to have a
separate standard for every anti-malware approach, for example.
Time and Resources

Doing security standards governance right takes time and resources. Spending a year building a set
of 15 documents, and then not having the committed resources to maintain them leads to increasing
irrelevancy over time. All stakeholders must be given the time and motivation to contribute to the
process effectively.
Keeping the document set well-structured, its ownership clear, and maintaining a timetable for its
ongoing review will help by making resource demands predictable.
Ensure that the incident response process includes an after-action review or equivalent so that an
opportunity to test both the standard and compliance issues is included. When “what could we have
done better” is included as a standard component of a repeating process, the resource issue
becomes less onerous.
Risk Management Dependency

A critical dependency of this approach is risk management and risk assessment. Without a risk
management framework, assessment and recording process, this guidance framework will be limited
in its effectiveness. Decisions on controls and context risk may be made inconsistently or without
enough justification, potentially leading the organization to major incidents, or even being
investigated for negligence or worse.
Success for this program does not require the risk-management process to be advanced. But it is
important that the organization has, at minimum:
■ A way of consistently assessing and measuring risk
■ An understanding of risk appetite
■ A consistent way of recording and periodically reviewing risk
Gartner research on risk methodologies can be found in the recommended reading section.
Compliance and Enforcement

A set of security standards documents on its own is just that — a set of documents. Unless they are
used by those responsible for implementing technology and processes, they provide no value.
Auditors will be pleased that the documents exist and are fit-for-purpose but will be concerned if the
organization appears to ignore them.
Enforcing compliance is subject to several issues, such as culture, prioritization, finance and senior
leadership support. If leadership has approved the standards, they must also be aware that they are
approving compliance enforcement efforts, with all that that implies.
Related Guidance
This guidance forms part of a program of research in Gartner for Technical Professionals addressing
security programs, risk management and security architecture. Please see the “Technology,
Information and Resilience Risk for Technical Professionals Primer for 2019” Gartner research for
more information on the future and direction of this program. Gartner for Technical Professionals
documents that are closely linked to this guidance include:
“Improve Your Security With Security Architecture”
“A Guidance Framework for Establishing Your Approach to Security Architecture”
“Developing Operational Security Metrics”
“Building the Foundations for Effective Security Hygiene”
Note 1
Internal IaaS Networks
The use of IaaS and virtualized platforms introduces various methods to provide and organize
communications between systems and applications. Software-defined networks can even
automatically group such entities, using a variety of approaches. However, this is an implementation
issue, not a security standards issue. You will still need to look at whether and how communications
can happen and the trust you have in the various networks that may exist.
Recommended by the Author

Improve Your Security With Security Architecture
A Guidance Framework for Establishing Your Approach to Security Architecture
Understanding and Managing Exceptions to Standards
Recommended For You

Security Frameworks: The What and Why, and How to Select Yours
Building the Foundations for Basic Security Hygiene
Security and Risk Management Programs for Technical Professionals Primer for 2020
How to Develop and Maintain Security Monitoring Use Cases
Improve Your Security With Security Architecture
© 2020 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. and its
affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior written
permission. It consists of the opinions of Gartner's research organization, which should not be construed as
statements of fact. While the information contained in this publication has been obtained from sources believed to
be reliable, Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information.
Although Gartner research may address legal and financial issues, Gartner does not provide legal or investment
advice and its research should not be construed or used as such. Your access and use of this publication are
governed by Gartner’s Usage Policy Gartner prides itself on its reputation for independence and objectivity Its
governed by Gartner s Usage Policy. Gartner prides itself on its reputation for independence and objectivity. Its
research is produced independently by its research organization without input or influence from any third party. For
further information, see "Guiding Principles on Independence and Objectivity."
About Gartner Careers Newsroom Policies Privacy Policy Contact Us Site Index Help Get the App
© 2020 Gartner, Inc. and/or its Affiliates. All rights reserved.

Creating Security Standards - Context, Structure and Must-Have Content

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Creating Security Standards - Context, Structure and Must-Have Content

Uploaded by

Copyright:

Available Formats

21/7/2020 Creating Security Standards: Context, Structure and Must-Have Content

Licensed for Distribution

This research note is restricted to the personal use of Celenia Varela

Creating Security Standards: Context, Structure and Must-

Structuring the Governance

Standards frameworks should be applied as part of a business needs assessment, documented in

Security governance should comprise of different types of documents targeted to different

Figure 1. Security Governance Structure

If your organization has no formal security policy or standards, it must

Approach selection for an organization depends on several factors, including:

■ Data and the regulated environment

■ Risks and threats to the business and its stakeholders

■ Complexity of the IT environment

■ Risk management approach adopted

■ Style of management and culture

■ Security and incident history

■ Organizational culture and preference

Policies and Standards — a Clariﬁcation

The Importance of Classifying Data

Deciding the Governance Level

Security standards set the minimum requirements for protecting an asset

Figure 2. Positioning the Security Standard

The Gartner Approach

The Guidance Framework

Figure 3. Gartner Process Framework for Security Standards Development

If possible, ensure that some form of risk management process, however

Identify Standards Committee and Contributors

The committee should be composed of individuals who are:

Security is often perceived as conflicting with other requirements. Resolving

There are three types of contributors: technical, business and functional.

Technical contributors can offer support in various ways:

■ A view of known risks and issues that need to be managed.

Business contributor support includes:

Functional contributors support includes:

■ Ensuring critical dependencies are in place.

■ Keeping personnel lists and processes reliable.

At a minimum, start and maintain an informal discussion with stakeholders

Identify Influences and Constraints

Involve Risk Management Process

Determine Control Requirements

Identify the Domains for Coverage

Enterprise and Security Technology Architecture

Table 1: Enterprise Architecture Approach

Servers Windows, Server operating systems may be unable to implement

Applications Commercial- Applications vary in capability and need to support security

Source: Gartner (May 2019)

Table 2: Security Controls Approach

Control Application Notes

Authentication Defines minimum Include a variety of controls such as passwords and

Network Defines the minimum If network segmentation is used to group systems or

Control Application Notes

Source: Gartner (May 2019)

A Hybrid Approach Provides the Best Outcome

■ Authentication security standard (control)

■ Log management speciﬁcation (domain)

■ Cryptography security standard (control)

■ Database security standard (domain)

■ Network security standard (control or domain, depending on approach)

■ Authentication security standard (control)

■ Remote access security standard (domain)

■ Network security standard (control or domain)

■ Gateway speciﬁcation (domain)

■ Cryptography security standard (control)