WRITTEN INFORMATION SECURITY

PROGRAM (WISP)

ACME Business Solutions, Inc.

 TABLE OF CONTENTS

WRITTEN INFORMATION SECURITY PROGRAM (WISP) OVERVIEW 7

INTRODUCTION 7
PURPOSE 7
SCOPE & APPLICABILITY 8
POLICY OVERVIEW 8
VIOLATIONS 8
EXCEPTIONS 8
UPDATES 8
KEY TERMINOLOGY 10
INFORMATION SECURITY PROGRAM STRUCTURE 12
MANAGEMENT DIRECTION FOR INFORMATION SECURITY 12
POLICIES, STANDARDS, PROCEDURES & GUIDELINES STRUCTURE 12
CYBERSECURITY GOVERNANCE (GOV) 13
GOV-1: PUBLISHING CYBERSECURITY POLICIES & STANDARDS 13
GOV-2: PERIODIC REVIEW & UPDATE OF CYBERSECURITY DOCUMENTATION 13
GOV-3: ASSIGNED CYBERSECURITY RESPONSIBILITIES 13
GOV-4: MEASURES OF PERFORMANCE 14
ASSET MANAGEMENT (AST) 15
AST-1: ASSET GOVERNANCE 15
AST-2: ASSET INVENTORIES 15
AST-3: ASSIGNING OWNERSHIP OF ASSETS 15
AST-4: NETWORK DIAGRAMS 16
AST-5: SECURE DISPOSAL OR RE-USE OF EQUIPMENT 16
AST-6: REMOVAL OF ASSETS 16
AST-7: SECURITY OF ASSETS OFF-PREMISES 16
BUSINESS CONTINUITY & DISASTER RECOVERY (BCD) 17
BCP-1: CONTINGENCY PLAN 17
BCP-2: CONTINGENCY TRAINING 17
BCP-3: CONTINGENCY PLAN TESTING & EXERCISES 18
BCP-4: CONTINGENCY PLAN ROOT CAUSE ANALYSIS (RCA) & LESSONS LEARNED 18
BCP-5: CONTINGENCY PLAN UPDATE 18
BCP-6: INFORMATION SYSTEM RECOVERY & RECONSTITUTION 18
CAPACITY & PERFORMANCE PLANNING (CAP) 19
CAP-1: CAPACITY MANAGEMENT 19
CAP-2: RESOURCE PRIORITY 19
CHANGE MANAGEMENT (CHG) 20
CHG-1: CONFIGURATION CHANGE CONTROL 20
CHG-2: SECURITY IMPACT ANALYSIS FOR CHANGES 20
CHG-3: SECURITY FUNCTIONALITY VERIFICATION 21
COMPLIANCE (CPL) 22
CPL-1: STATUTORY, REGULATORY & CONTRACTUAL COMPLIANCE 22
CPL-2: SECURITY CONTROLS OVERSIGHT 22
CPL-3: SECURITY ASSESSMENTS 23
CONFIGURATION MANAGEMENT (CFG) 24
CFG-1: SYSTEM HARDENING THROUGH BASELINE CONFIGURATIONS 24
CFG-2: LEAST FUNCTIONALITY 24
CFG-3: SOFTWARE USAGE RESTRICTIONS 25
CONTINUOUS MONITORING (MON) 26
MON-1: CONTINUOUS MONITORING 26
MON-2: CENTRALIZED EVENT LOG COLLECTION 27
MON-3: CONTENT OF AUDIT RECORDS 27

NIST Cybersecurity Framework WISP - Version 2018.1 Page 2 of 112

 MON-4: MONITORING REPORTING 27
MON-5: TIME STAMPS 28
MON-6: ANOMALOUS BEHAVIOR 28
MON-7: THIRD-PARTY THREATS 28
MON-8: PRIVILEGED USERS 28
MON-9: UNAUTHORIZED ACTIVITIES 28
CRYPTOGRAPHIC PROTECTIONS (CRY) 30
CRY-1: USE OF CRYPTOGRAPHIC PROTECTIONS 30
CRY-2: TRANSMISSION CONFIDENTIALITY 30
CRY-3: TRANSMISSION INTEGRITY 31
CRY-4: ENCRYPTING DATA AT REST 31
DATA CLASSIFICATION & HANDLING (DCH) 32
DCH-1: DATA PROTECTION 32
DCH-2: DATA & ASSET CLASSIFICATION 32
DCH-3: MEDIA TRANSPORTATION 32
DCH-4: MEDIA SANITIZATION & DISPOSAL 33
DCH-5: SYSTEM OUTPUT HANDLING & DATA RETENTION 33
DCH-6: REMOVABLE MEDIA SECURITY 34
DCH-7: USE OF EXTERNAL INFORMATION SYSTEMS 34
DCH-8: INFORMATION SHARING 34
DCH-9: PUBLICLY ACCESSIBLE CONTENT 34
DCH-10: GEOGRAPHIC LOCATION OF DATA 35
ENDPOINT SECURITY (END) 36
END-1: WORKSTATION SECURITY 36
END-2: ENDPOINT PROTECTION MEASURES 36
END-3: MALICIOUS CODE PROTECTION (ANTIMALWARE) 36
END-4: AUTOMATIC ANTIMALWARE UPDATES 37
END-5: ANTIMALWARE ALWAYS-ON PROTECTION 37
END-6: FILE INTEGRITY MONITORING (FIM) 37
END-7: SOFTWARE FIREWALL 38
END-8: PHISHING & SPAM PROTECTION 38
END-9: MOBILE CODE 38
HUMAN RESOURCES SECURITY (HRS) 40
HRS-1: HUMAN RESOURCES SECURITY MANAGEMENT 40
HRS-2: POSITION CATEGORIZATION 40
HRS-3: USERS WITH ELEVATED PRIVILEGES 40
HRS-4: ROLES & RESPONSIBILITIES 40
HRS-5: PERSONNEL SCREENING 41
HRS-6: TERMS OF EMPLOYMENT 41
HRS-7: RULES OF BEHAVIOR 41
HRS-8: ACCESS AGREEMENTS 41
HRS-9: PERSONNEL SANCTIONS 42
HRS-10: PERSONNEL TRANSFER 42
HRS-11: PERSONNEL TERMINATION 42
HRS-12: THIRD-PARTY PERSONNEL SECURITY 42
IDENTIFICATION & AUTHENTICATION (IAC) 44
IAC-1: IDENTIFICATION & AUTHENTICATION 44
IAC-2: MULTIFACTOR AUTHENTICATION (MFA) 44
IAC-3: USER PROVISIONING & DE-PROVISIONING 44
IAC-4: ROLE-BASED ACCESS CONTROL (RBAC) 45
IAC-5: IDENTIFIER MANAGEMENT (USER NAMES) 45
IAC-6: AUTHENTICATOR MANAGEMENT (PASSWORDS) 45
IAC-7: PASSWORD AUTHENTICATION MANAGEMENT 45
IAC-8: ACCOUNT MANAGEMENT 47
IAC-9: PERIODIC REVIEW 47
IAC-10: LEAST PRIVILEGE 48

NIST Cybersecurity Framework WISP - Version 2018.1 Page 3 of 112

INCIDENT RESPONSE (IRO) 49
IRO-1: INCIDENTS RESPONSE OPERATIONS 49
IRO-2: INCIDENT HANDLING 49
IRO-3: INCIDENT RESPONSE PLAN (IRP) 49
IRO-4: INCIDENT RESPONSE TRAINING 50
IRO-5: INCIDENT RESPONSE TESTING 50
IRO-6: INTEGRATED INCIDENT RESPONSE TEAM 50
IRO-7: CHAIN OF CUSTODY & FORENSICS 51
IRO-8: INCIDENT MONITORING 51
IRO-9: INCIDENT REPORTING 51
IRO-10: ROOT CAUSE ANALYSIS (RCA) & LESSONS LEARNED 51
IRO-11: IRP UPDATE 52
MAINTENANCE (MNT) 53
MNT-1: MAINTENANCE OPERATIONS 53
MNT-2: CONTROLLED MAINTENANCE 53
MNT-3: TIMELY MAINTENANCE 53
MNT-4: REMOTE MAINTENANCE 54
NETWORK SECURITY (NET) 55
NET-1: LAYERED DEFENSES 55
NET-3: BOUNDARY PROTECTIONS 55
NET-3: DATA FLOW ENFORCEMENT (ACCESS CONTROL LISTS) 56
NET-4: INFORMATION SYSTEM CONNECTIONS 56
NET-5: SECURITY FUNCTION ISOLATION 56
NET-6: VIRTUAL LOCAL AREA NETWORK (VLAN) SEPARATION 57
NET-7: GUEST NETWORKS 57
NET-8: NETWORK DISCONNECT 57
NET-9: NETWORK INTRUSION DETECTION & PREVENTION SYSTEMS (NIDS/NIPS) 57
NET-10: SAFEGUARDING DATA OVER OPEN NETWORKS 58
NET-11: REMOTE ACCESS 58
PHYSICAL & ENVIRONMENTAL SECURITY (PES) 59
PES-1: PHYSICAL & ENVIRONMENTAL PROTECTIONS 59
PES-2: PHYSICAL ACCESS CONTROL 59
PES-3: MONITORING PHYSICAL ACCESS 59
PES-4: VISITOR CONTROL 60
PES-5: INFORMATION LEAKAGE DUE TO ELECTROMAGNETIC SIGNALS EMANATIONS 60
PROJECT & RESOURCE MANAGEMENT (PRM) 61
PRM-1: ALLOCATION OF RESOURCES 61
PRM-2: SECURITY REQUIREMENTS DEFINITION 61
PRM-3: SECURITY IN PROJECT MANAGEMENT 61
PRM-4: SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) 62
RISK MANAGEMENT (RSK) 63
RSK-1: RISK MANAGEMENT PROGRAM (RMP) 63
RSK-2: RISK IDENTIFICATION 63
RSK-3: RISK ASSESSMENT 63
RSK-4: RISK RANKING 64
RSK-5: RISK REMEDIATION 64
RSK-6: BUSINESS IMPACT ASSESSMENTS (BIAS) 64
SECURE ENGINEERING & ARCHITECTURE (SEA) 65
SEA-1: SECURITY ENGINEERING PRINCIPLES 65
SEA-2: SECURE CONFIGURATIONS 65
SEA-3: LEAST FUNCTIONALITY 66
SEA-4: FAIL SECURE IN KNOWN STATE 66
SEA-5: CLOCK SYNCHRONIZATION 67
SECURITY OPERATIONS (OPS) 68
OPS-1: OPERATIONS SECURITY 68

NIST Cybersecurity Framework WISP - Version 2018.1 Page 4 of 112

 OPS-2: STANDARDIZED OPERATING PROCEDURES (SOPS) 68
SECURITY AWARENESS & TRAINING (SAT) 69
SAT-1: SECURITY-MINDED WORKFORCE 69
SAT-2: SECURITY AWARENESS 69
SAT-3: SECURITY TRAINING 70
SAT-4: SECURITY TRAINING RECORDS 70
TECHNOLOGY DEVELOPMENT & ACQUISITION (TDA) 71
TDA-1: TECHNOLOGY DEVELOPMENT & ACQUISITION 71
TDA-2: SECURITY REQUIREMENTS 71
TDA-3: DESIGN & IMPLEMENTATION OF SECURITY CONTROLS 71
TDA-4: FUNCTIONAL PROPERTIES OF SECURITY CONTROLS 71
TDA-5: SECURE DEVELOPMENT 71
TDA-6: SECURE DEVELOPMENT ENVIRONMENTS 72
TDA-7: SEPARATION OF DEVELOPMENT, TESTING & OPERATIONAL ENVIRONMENTS 72
TDA-8: SECURITY TESTING THROUGHOUT DEVELOPMENT 72
THIRD-PARTY MANAGEMENT (TPM) 74
TPM-1: THIRD-PARTY MANAGEMENT 74
TPM-2: THIRD-PARTY CRITICALITY ASSESSMENTS 74
TPM-3: SUPPLY CHAIN PROTECTION 74
TPM-4: THIRD-PARTY SERVICES 75
TPM-5: WRITTEN CONTRACT REQUIREMENTS 75
TPM-6: REVIEW OF THIRD-PARTY SERVICES 75
TPM-7: THIRD-PARTY DEFICIENCY REMEDIATION 76
TPM-8: MANAGING CHANGES TO THIRD-PARTY SERVICES 76
TPM-9: THIRD-PARTY INCIDENT RESPONSE & RECOVERY CAPABILITIES 76
THREAT MANAGEMENT (THR) 77
THR-1: THREAT AWARENESS PROGRAM 77
THR-2: THREAT INTELLIGENCE FEEDS 77
VULNERABILITY & PATCH MANAGEMENT (VPM) 78
VPM-1: VULNERABILITY & PATCH MANAGEMENT PROGRAM 78
VPM-2: VULNERABILITY RANKING 78
VPM-3: VULNERABILITY REMEDIATION 78
VPM-4: SOFTWARE PATCHING 79
VPM-5: VULNERABILITY SCANNING 79
VPM-6: RED TEAM EXERCISES 79
WEB SECURITY (WEB) 80
WEB-1: USE OF DEMILITARIZED ZONES (DMZ) 80
WEB-2: CLOUD PROVIDERS 80
WEB-3: CLOUD SECURITY ARCHITECTURE 80
WEB-4: SECURITY MANAGEMENT SUBNET 81
WEB-5: MULTI-TENANT ENVIRONMENTS 81
WEB-6: GEOLOCATION REQUIREMENTS 81
WEB-7: SENSITIVE DATA IN PUBLIC CLOUD PROVIDERS 81
WRITTEN INFORMATION SECURITY PROGRAM (WISP) APPENDICES 82
APPENDIX A: DATA CLASSIFICATION & HANDLING GUIDELINES 82
A-1: DATA CLASSIFICATION 82
A-2: LABELING 83
A-3: GENERAL ASSUMPTIONS 83
A-4: PERSONALLY IDENTIFIABLE INFORMATION (PII) 83
APPENDIX B: DATA CLASSIFICATION EXAMPLES 86
APPENDIX C: DATA RETENTION PERIODS 88
APPENDIX D: BASELINE SECURITY CATEGORIZATION GUIDELINES 90
D-1: DATA SENSITIVITY 90
D-2: SAFETY & CRITICALITY 90
D-3: BASIC ASSURANCE REQUIREMENTS 91

NIST Cybersecurity Framework WISP - Version 2018.1 Page 5 of 112

 D-4: ENHANCED ASSURANCE REQUIREMENTS 91
APPENDIX E: INFORMATION SECURITY ROLES & RESPONSIBILITIES 92
E-1: INFORMATION SECURITY ROLE CATEGORIES 92
E-2: INFORMATION SECURITY SPECIALTY AREAS (ROLES) 93
E-3: INFORMATION SECURITY WORK ROLES & RESPONSIBILITIES 96
APPENDIX F: RULES OF BEHAVIOR / USER ACCEPTABLE USE 101
F-1: ACCEPTABLE USE 101
F-2: PROHIBITED USE 101
F-3: GUIDANCE ON THE PERSONAL USE OF COMPANY-OWNED TECHNOLOGY 102
F-4: ADDITIONAL RULES FOR SECURITY & PRIVILEGED USERS 102
GLOSSARY: ACRONYMS & DEFINITIONS 104
ACRONYMS 104
DEFINITIONS 104
KEY WORD INDEX 105
RECORD OF CHANGES 106
ANNEX 1 – CYBERSECURITY POLICIES 108
CYBERSECURITY GOVERNANCE (GOV) 108
ASSET MANAGEMENT (AST) 108
BUSINESS CONTINUITY & DISASTER RECOVERY (BCD) 108
CAPACITY & PERFORMANCE PLANNING (CAP) 108
CHANGE MANAGEMENT (CHG) 108
COMPLIANCE (CPL) 108
CONFIGURATION MANAGEMENT (CFG) 109
CONTINUOUS MONITORING (MON) 109
CRYPTOGRAPHIC PROTECTIONS (CRY) 109
DATA CLASSIFICATION & HANDLING (DCH) 109
ENDPOINT SECURITY (END) 109
HUMAN RESOURCES SECURITY (HRS) 110
IDENTIFICATION & AUTHENTICATION (IAC) 110
INCIDENT RESPONSE (IRO) 110
MAINTENANCE (MNT) 110
NETWORK SECURITY (NET) 110
PHYSICAL & ENVIRONMENTAL SECURITY (PES) 110
PROJECT & RESOURCE MANAGEMENT (PRM) 111
RISK MANAGEMENT (RSK) 111
SECURE ENGINEERING & ARCHITECTURE (SEA) 111
SECURITY OPERATIONS (OPS) 111
SECURITY AWARENESS & TRAINING (SAT) 111
TECHNOLOGY DEVELOPMENT & ACQUISITION (TDA) 111
THIRD-PARTY MANAGEMENT (TPM) 112
THREAT MANAGEMENT (THR) 112
VULNERABILITY & PATCH MANAGEMENT (VPM) 112

NIST Cybersecurity Framework WISP - Version 2018.1 Page 6 of 112

WRITTEN INFORMATION SECURITY PROGRAM (WISP) OVERVIEW

INTRODUCTION
The Written Information Security Program (WISP) provides definitive information on the prescribed measures used to establish and
enforce the cybersecurity program at ACME Business Solutions, Inc. (ACME).

ACME is committed to protecting its employees, partners, clients and ACME from damaging acts that are intentional or
unintentional. Effective cybersecurity is a team effort involving the participation and support of every ACME user who interacts with
data and systems. Therefore, it is the responsibility of every user to know these policies and to conduct their activities accordingly.

Protecting company data and the systems that collect, process, and maintain this information is of critical importance. Consequently,
the security of systems must include controls and safeguards to offset possible threats, as well as controls to ensure availability,
integrity, confidentiality and safety:

 CONFIDENTIALITY – Confidentiality addresses preserving

restrictions on information access and disclosure so
that access is limited to only authorized users and
services.

 INTEGRITY – Integrity addresses the concern that

sensitive data has not been modified or deleted in an
unauthorized and undetected manner.

 AVAILABILITY – Availability addresses ensuring timely

and reliable access to and use of information.

 SAFETY – Safety addresses reducing risk associated with

embedded technologies that could fail or be
manipulated to cause physical impact by nefarious
actors.

Commensurate with risk, security measures must be implemented to guard against unauthorized access to, alteration, disclosure
or destruction of data and systems. This also includes protection against accidental loss or destruction.

PURPOSE
The purpose of the Written Information Security Program (WISP) is to prescribe a comprehensive framework for:
 Creating a leading practice-based Information Security Management System (ISMS) that is structured on the NIST
Cybersecurity Framework (CSF);1
 Protecting the confidentiality, integrity, and availability of ACME data and systems;
 Protecting ACME, its employees, and its clients from illicit use of ACME systems and data;
 Ensuring the effectiveness of security controls over data and systems that support ACME’s operations.
 Recognizing the highly-networked nature of the current computing environment and provide effective company-wide
management and oversight of those related cybersecurity risks; and
 Providing for the development, review, and maintenance of minimum security controls required to protect ACME’s data
and systems.

The formation of these cybersecurity policies is driven by many factors, with the key factor being a risk. These policies set the ground
rules under which ACME operates and safeguards its data and systems to both reduce risk and minimize the effect of potential
incidents.

These policies, including their related control objectives, standards, procedures, and guidelines, are necessary to support the
management of information risks in daily operations. The development of policies provides due care to ensure ACME users
understand their day-to-day security responsibilities and the threats that could impact the company.

1
NIST Cybersecurity Framework (CSF) - https://www.nist.gov/cyberframework

NIST Cybersecurity Framework WISP - Version 2018.1 Page 7 of 112

Implementing consistent security controls across the company will help ACME comply with current and future legal obligations to
ensure long-term due diligence in protecting the confidentiality, integrity and availability of ACME data.

SCOPE & APPLICABILITY

These policies, standards and guidelines apply to all ACME data, systems, activities, and assets owned, leased, controlled, or used
by ACME, its agents, contractors, or other business partners on behalf of ACME. These policies, standards and guidelines apply to
all ACME employees, contractors, sub-contractors, and their respective facilities supporting ACME business operations, wherever
ACME data is stored or processed, including any third-party contracted by ACME to handle, process, transmit, store, or dispose of
ACME data.

Some standards apply specifically to persons with a specific job function (e.g., a System Administrator); otherwise, all personnel
supporting ACME business functions shall comply with the standards. ACME departments shall use these standards or may create a
more restrictive standard, but none that are less restrictive, less comprehensive, or less compliant than these standards.

These policies do not supersede any other applicable law or higher-level company directive or existing labor management
agreement in effect as of the effective date of this policy.

Appendix E: Information Security Roles & Responsibilities provides a detailed description of ACME user roles and responsibilities, in
regards to Information Security.

ACME reserves the right to revoke, change, or supplement these policies, standards and guidelines at any time without prior notice.
Such changes shall be effective immediately upon approval by management unless otherwise stated.

POLICY OVERVIEW
To ensure an acceptable level of cybersecurity risk, ACME is required to design, implement and maintain a coherent set of policies,
standards, procedures and guidelines to manage risks to its data and systems.

The WISP addresses the policies, standards and guidelines. Data/process owners, in conjunction with asset custodians, are
responsible for creating, implementing and updated operational procedures to comply with WISP requirements.

ACME users are required to protect and ensure the Confidentiality, Integrity, Availability and Safety (CIAS) of data and systems,
regardless of how its data is created, distributed or stored.
 Security controls will be tailored accordingly so that cost-effective controls can be applied commensurate with the risk and
sensitivity of the data and system; and
 Security controls must be designed and maintained to ensure compliance with all legal requirements.

VIOLATIONS
Any ACME user found to have violated any policy, standard or procedure may be subject to disciplinary action, up to and including
termination of employment. Violators of local, state, Federal, and/or international law may be reported to the appropriate law
enforcement agency for civil and/or criminal prosecution.

EXCEPTIONS
While every exception to a standard potentially weakens protection mechanisms for ACME systems and underlying data,
occasionally exceptions will exist. When requesting an exception, users are required to submit a business justification for deviation
from the standard in question.

UPDATES
Updates to the Written Information Security Program (WISP) will be announced to employees via management updates or email
announcements. Changes will be noted in the Record of Changes to highlight the pertinent changes from the previous policies,
procedures, standards and guidelines.

NIST Cybersecurity Framework WISP - Version 2018.1 Page 8 of 112

Least Privilege: A term describing the theory of restricting access by only allowing users or processes the least set of privileges
necessary to complete a specific job or function.

Personal Data / Personally Identifiable Information (PII). A term describing any information relating to an identified or identifiable
natural person ("data subject"); an identifiable person is one who can be identified, directly or indirectly, in particular by reference
to an identifier such as a name, an identification number, location data, online identifier or to one or more factors specific to the
physical, physiological, genetic, mental, economic, cultural or social identity of that person. 3

PII Controller / Data Controller. A term describing the privacy stakeholder (or privacy stakeholders) that determines the purposes
and means for processing personally identifiable information (PII) other than natural persons who use data for personal purposes

PII Principal / Data Principle. A term describing the natural person to whom the personally identifiable information (PII) relates

PII Processor / Data Processor. A term describing the privacy stakeholder that processes personally identifiable information (PII) on
behalf of and in accordance with the instructions of a PII controller

Policy: A term describing a formally established requirement to guide decisions and achieve rational outcomes. Essentially, a policy
is a statement of expectation that is enforced by standards and further implemented by procedures.

Procedure: A term describing an established or official way of doing something, based on a series of actions conducted in a certain
order or manner. Procedures are the responsibility of the asset custodian to build and maintain, in support of standards and policies.

Sensitive Data: A term that covers categories of data that must be kept secure. Examples of sensitive data include sensitive
Personally Identifiable Information (sPII), Electronic Protected Health Information (ePHI), and all other forms of data classified as
Restricted or Confidential in Appendix A: Data Classification & Handling Guidelines.

Sensitive Personal Data / Sensitive Personally Identifiable Information (sPII): A term describing personal data, revealing:
 The first name or first initial and last name, in combination with any one or more of the following data elements: 4
o Social Security Number (SSN) / Taxpayer Identification Number (TIN) / National Identification Number (NIN);
o Driver License (DL) or another government-issued identification number (e.g., passport, permanent resident card,
etc.);
o Financial account number; or
o Payment card number (e.g., credit or debit card);
 Racial or ethnic origin;
 Political opinions;
 Religious or philosophical beliefs;
 Trade-union membership;
 Physical or mental health;
 Sex life and sexual orientation;
 Genetic data; and/or
 Biometric data.5

Standard: A term describing formally established requirements in regard to processes, actions, and configurations.

System: A term describing an asset; an information system or network that can be defined, scoped, and managed. Includes, but is
not limited to, computers, workstations, laptops, servers, routers, switches, firewalls, and mobile devices.

Target Audience: A term describing the intended group for which a control or standard is directed.

3
European Union General Data Protection Requirement – Article 4(1)
4
The source of this definition comes from two state laws - Oregon Consumer Identity Theft Protection Act - ORS 646A.600(11)(a) -
http://www.leg.state.or.us/ors/646a.html and Massachusetts 201 CMR 17.00” Standards For The Protection of Personal
Information of Residents of The Commonwealth - MA201CMR17.02
http://www.mass.gov/ocabr/docs/idtheft/201cmr1700reg.pdf
5
European Union General Data Protection Requirement – Article 9(1)

NIST Cybersecurity Framework WISP - Version 2018.1 Page 11 of 112

INFORMATION SECURITY PROGRAM STRUCTURE

MANAGEMENT DIRECTION FOR INFORMATION SECURITY

The objective is to provide management direction and support for cybersecurity in accordance with business requirements and
relevant laws and regulations. 6

An Information Security Management System (ISMS) focuses on cybersecurity management and technology-related risks. The
governing principle behind ACME’s ISMS is that, as with all management processes, the ISMS must remain effective and efficient in
the long-term, adapting to changes in the internal organization and external environment.

In accordance with leading practices, ACME’s ISMS incorporates the typical "Plan-Do-Check-Act" (PDCA), or Deming Cycle, approach:
 Plan: This phase involves designing the ISMS, assessing IT-related risks, and selecting appropriate controls.
 Do: This phase involves implementing and operating the appropriate security controls.
 Check: This phase involves reviewing and evaluating the performance (efficiency and effectiveness) of the ISMS.
 Act: This involves making changes, where necessary, to bring the ISMS back to optimal performance.

POLICIES, STANDARDS, PROCEDURES & GUIDELINES STRUCTURE

Information security documentation is comprised of five main parts: a core policy; a control objective that identifies desired
conditions; measurable standards used to quantify the requirement; procedures that must be followed; and guidelines that are
recommended, but not mandatory.

Information security documentation is comprised of five main parts:

(1) Core policy that establishes management’s intent;
(2) Control objective that identifies the condition that should be met;
(3) Standards that provides quantifiable requirements to be met;
(4) Procedures that establish how tasks must be performed to meet the requirements established in standards; and
(5) Guidelines are recommended, but not mandatory.

Figure 1: Information Security Documentation Framework

6
ISO 27002 5.1

NIST Cybersecurity Framework WISP - Version 2018.1 Page 12 of 112

CAPACITY & PERFORMANCE PLANNING (CAP)

Management Intent: The purpose of the Capacity & Performance Planning (CAP) policy is to prevent avoidable business interruptions
caused by capacity and performance limitations through requiring both technology and business leadership to maintain situational
awareness of current and future performance.

Policy: ACME shall protect against avoidable impacts to operations by proactively managing the capacity and performance of its
critical technology and supporting infrastructure.

Supporting Documentation: This policy is supported by the following control objectives, standards, and guidelines.

CAP-1: CAPACITY MANAGEMENT

Standard: Asset custodians and data/process owners are required to allocate sufficient processing and storage capacity to reduce
the likelihood of exceeding capacity that could negatively impact functionality:
(a) The availability, quality, and adequate capacity and resources shall be planned, prepared, and measured to deliver the
required system performance by legal, statutory, and regulatory compliance obligations; and
(b) Projections of future capacity requirements shall be made to mitigate the risk of system overload.

Guidelines: Data/process owners must consider the types of auditing to be performed and the audit processing requirements when
allocating audit storage capacity. Allocating sufficient audit storage capacity reduces the likelihood of such capacity being exceeded
and resulting in the potential loss or reduction of auditing capability.

CAP-2: RESOURCE PRIORITY

Standard: Asset custodians and data/process owners are required to prioritize resources to prevent or limit Denial of Service (DoS)
attack effectiveness.

Guidelines: Priority protection helps prevent lower-priority processes from delaying or interfering with the system servicing any
higher-priority processes. Quotas prevent users or processes from obtaining more than predetermined amounts of resources. This
control does not apply to system components for which there are only single users/roles.

NIST Cybersecurity Framework WISP - Version 2018.1 Page 19 of 112

 (e) Removing all unnecessary functionality, such as:
1. Scripts;
2. Drivers;
3. Features;
4. Subsystems;
5. File systems; and
6. Unnecessary web servers.

Guidelines: Asset custodians should review functions and services of systems, to determine which functions and services are
candidates for elimination (e.g., Instant Messaging, SMS, auto-execute, and file sharing). ACME may utilize network scanning tools,
intrusion detection and prevention systems, and endpoint protections such as firewalls and host-based intrusion detection systems
to identify and prevent the use of prohibited functions, ports, protocols, and services.

CFG-3: SOFTWARE USAGE RESTRICTIONS

Standard: Users are required to implement and utilize software in accordance with license agreements and copyright laws.

Guidelines: The software inventory system should track the version of the underlying operating system as well as the applications
installed on it. The software inventory systems should be tied into the hardware asset inventory, so all devices and associated
software are tracked from a single location. Tracking systems can include, for example, simple spreadsheets or fully automated,
specialized applications depending on organizational needs. ACME should:
 Employ tracking systems for software and associated documentation protected by quantity licenses to control copying and
distribution; and
 Control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the
unauthorized distribution, display, performance, or reproduction of copyrighted work.

NIST Cybersecurity Framework WISP - Version 2018.1 Page 25 of 112

CONTINUOUS MONITORING (MON)

Management Intent: The purpose of the Continuous Monitoring (MON) policy is to establish and maintain situational awareness
across the enterprise through the centralized collection and review of security-related event logs. Without comprehensive visibility
into infrastructure, operating system, database, application and other logs, ACME will have “blind spots” in its situational awareness
that could lead to system compromise and/or data exfiltration.

Policy: Only through the ongoing and continuous monitoring of ACME’s technology assets can situation awareness of cybersecurity
events be maintained. Therefore, technology assets must adhere to configuration management requirements to log security events
and forward those events to allow for the centralized monitoring and review of logs to identify anomalous behavior so that
appropriate steps can be taken to remediate potential cybersecurity incidents.

Supporting Documentation: This policy is supported by the following control objectives, standards, and guidelines.

MON-1: CONTINUOUS MONITORING

Standard: Data/process owners and asset custodians are required to develop and implement processes to capture, protect and
review logs from all system components in accordance with ACME requirements to centrally manage and identify anomalies or
suspicious activity that includes, but is not limited to:
(a) Reviewing the following, at least daily:
1. All security events;
2. Logs of all system components that store, process, or transmit cardholder data, or that could impact the security
of cardholder data;
3. Logs of all critical system components; and
4. Logs of all servers and system components that perform security functions. This includes, but is not limited to:
i. Firewalls
ii. Intrusion Detection Systems (IDS)
iii. Intrusion Prevention Systems (IPS)
iv. Authentication servers (e.g., Active Directory domain controllers); and
v. E-commerce redirection servers;
(b) Reviewing logs of all other system components periodically based on ACME’s policies and risk management strategy, as
determined by ACME’s annual risk assessment;
(c) Following up exceptions and anomalies identified during the review process;
(d) Developing processes for the timely detection and reporting of failures of critical security control systems, including but
not limited to failure of:
1. Firewalls;
2. IDS/IPS;
3. FIM;
4. Anti-malware;
5. Physical access controls;
6. Logical access controls;
7. Audit logging mechanisms; and
8. Segmentation controls (if used); and
(e) Responding to failures of any critical security controls in a timely manner. Processes for responding to failures in security
controls must include:
1. Restoring security functions;
2. Identifying and documenting the duration (date and time start to end) of the security failure;
3. Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to
address root cause;
4. Identifying and addressing any security issues that arose during the failure;
5. Performing a risk assessment to determine whether further actions are required as a result of the security failure;
6. Implementing controls to prevent cause of failure from reoccurring; and
7. Resuming monitoring of security controls.

Guidelines: Generating audit trails of suspect activities alerts the system administrator, sends data to other monitoring mechanisms
(like intrusion detection systems), and provides a history trail for post-incident follow-up. Logging of the following events enables

NIST Cybersecurity Framework WISP - Version 2018.1 Page 26 of 112

WRITTEN INFORMATION SECURITY PROGRAM (WISP) APPENDICES

APPENDIX A: DATA CLASSIFICATION & HANDLING GUIDELINES

A-1: DATA CLASSIFICATION

Information assets are assigned a sensitivity level based on the appropriate audience for the information. If the information has
been previously classified by regulatory, legal, contractual, or company directive, then that classification will take precedence. The
sensitivity level then guides the selection of protective measures to secure the information. All data are to be assigned one of the
following four sensitivity levels:

Classification Data Classification Description

Restricted information is highly valuable, highly sensitive business information and the level
of protection is dictated externally by legal and/or contractual requirements. Restricted
Definition
information must be limited to only authorized employees, contractors, and business
partners with a specific business need.

Restricted · SIGNIFICANT DAMAGE would occur if Restricted information were to become available to
unauthorized parties either internal or external to ACME.
Potential
Impact of Loss · Impact could include negatively affecting ACME’s competitive position, violating regulatory
requirements, damaging the company’s reputation, violating contractual requirements, and
posing an identity theft risk.

Confidential information is highly valuable, sensitive business information and the level of
Definition
protection is dictated internally by ACME

· MODERATE DAMAGE would occur if Confidential information were to become available to

Confidential
unauthorized parties either internal or external to ACME.
Potential
Impact of Loss · Impact could include negatively affecting ACME’s competitive position, damaging the
company’s reputation, violating contractual requirements, and exposing the geographic
location of individuals.
Internal Use information is information originated or owned by ACME, or entrusted to it by
others. Internal Use information may be shared with authorized employees, contractors, and
Definition
business partners who have a business need, but may not be released to the general public,
due to the negative impact it might have on the company’s business interests.
Internal Use
· MINIMAL or NO DAMAGE would occur if Internal Use information were to become
Potential available to unauthorized parties either internal or external to ACME.
Impact of Loss · Impact could include damaging the company’s reputation and violating contractual
requirements.
Public information is information that has been approved for release to the general public
Definition
and is freely shareable both internally and externally.

Public · NO DAMAGE would occur if Public information were to become available to parties either
Potential internal or external to ACME.
Impact of Loss
· Impact would not be damaging or a risk to business operations.

NIST Cybersecurity Framework WISP - Version 2018.1 Page 82 of 112

A-2: LABELING
Labeling is the practice of marking a system or document with its appropriate sensitivity level so that others know how to
appropriately handle the information. There are several methods for labeling information assets.
 Printed. Information that can be printed (e.g., spreadsheets, files, reports, drawings, or handouts) should contain one of
the following confidentiality symbols in the document footer on every printed page (see below), or simply the words if the
graphic is not technically feasible. The exception for labeling is with marketing material, since marketing material is
primarily developed for public release.
 Displayed. Restricted or Confidential information that is displayed or viewed (e.g., websites, presentations, etc.) must be
labeled with its classification as part of the display.

A-3: GENERAL ASSUMPTIONS

 Any information created or received by ACME employees in the performance of their jobs at is Internal Use, by default,
unless the information requires greater confidentiality or is approved for release to the general public.
 Treat information that is not assigned a classification level as “Internal Use” at a minimum and use corresponding controls.
 When combining information with different sensitivity levels into a single application or database, assign the most
restrictive classification of the combined asset. For example, if an application contains Internal Use and Confidential
information, the entire application is Confidential.
 Restricted, Confidential and Internal Use information must never be released to the general public but may be shared with
third parties, such as government agencies, business partners, or consultants, when there is a business need to do so and
the appropriate security controls are in place according to the level of classification.
 You may not change the format or media of information if the new format or media you will be using does not have the
same level of security controls in place. For example, you may not export Restricted information from a secured database
to an unprotected Microsoft Excel spreadsheet.

A-4: PERSONALLY IDENTIFIABLE INFORMATION (PII)

Personally Identifiable Information (PII) is defined as the first name or first initial and last name, in combination with any one or
more of the following data elements:
 Government-Issued Identification Number (e.g., passport, permanent resident card, etc.)
o Social Security Number (SSN) / Taxpayer Identification Number (TIN) / National Identification Number (NIN)
o Passport number
o Permanent resident card
 Driver License (DL)
 Financial account number
o Payment card number (credit or debit)
o Bank account number
 Electronic Protected Health Information (ePHI)

NIST Cybersecurity Framework WISP - Version 2018.1 Page 83 of 112

A-5: DATA HANDLING GUIDELINES

Handling Controls Restricted Confidential Internal Use Public

▪ NDA is required prior to ▪ NDA is recommended
access by non-ACME prior to access by non-
Non-Disclosure
employees. ACME employees. No NDA requirements No NDA requirements
Agreement (NDA)

▪ Encryption is required ▪ Encryption is

Internal Network ▪ Instant Messaging is recommended
Transmission prohibited ▪ Instant Messaging is No special requirements No special requirements
(wired & wireless) ▪ FTP is prohibited prohibited
▪ FTP is prohibited
▪ Encryption is required ▪ Encryption is required ▪ Encryption is
▪ Instant Messaging is ▪ Instant Messaging is recommended
prohibited prohibited ▪ Instant Messaging is
External Network ▪ FTP is prohibited ▪ FTP is prohibited prohibited
Transmission ▪ Remote access should ▪ FTP is prohibited No special requirements
(wired & wireless) be used only when
necessary and only with
VPN and two-factor
authentication
▪ Encryption is required ▪ Encryption is ▪ Encryption is ▪ Logical access controls
▪ Logical access controls recommended recommended are required to limit
Data At Rest are required to limit ▪ Logical access controls ▪ Logical access controls unauthorized use
(file servers, unauthorized use are required to limit are required to limit ▪ Physical access
databases, archives, ▪ Physical access unauthorized use unauthorized use restricted to specific
etc.) restricted to specific ▪ Physical access ▪ Physical access groups
individuals restricted to specific restricted to specific
groups groups
Mobile Devices ▪ Encryption is required ▪ Encryption is required ▪ Encryption is
(iPhone, iPad, MP3 ▪ Remote wipe must be ▪ Remote wipe must be recommended
enabled, if possible enabled, if possible ▪ Remote wipe should be No special requirements
player, USB drive,
etc.) enabled, if possible

Email ▪ Encryption is required ▪ Encryption is required ▪ Encryption is

(with and without ▪ Do not forward ▪ Do not forward recommended No special requirements
attachments)
▪ Mark “Open by ▪ Mark “Open by ▪ Mail with company
Addressee Only” Addressee Only” interoffice mail
▪ Use “Certified Mail” and ▪ Use “Certified Mail” and ▪ US Mail or other
sealed, tamper-resistant sealed, tamper-resistant public delivery
envelopes for external envelopes for external systems and sealed,
Physical Mail mailings mailings tamper-resistant No special requirements
▪ Delivery confirmation is ▪ Delivery confirmation is envelopes for external
required required mailings
▪ Hand deliver internally ▪ Hand delivering is
recommended over
interoffice mail
▪ Verify destination ▪ Verify destination ▪ Verify destination
printer printer printer
Printer ▪ Attend printer while ▪ Attend printer while ▪ Retrieve printed No special requirements
printing printing material without delay

NIST Cybersecurity Framework WISP - Version 2018.1 Page 84 of 112

APPENDIX B: DATA CLASSIFICATION EXAMPLES

The table below shows examples of common data instances that are already classified to simplify the process. This list is not inclusive
of all types of data, but it establishes a baseline for what constitutes data sensitivity levels and will adjust to accommodate new
types or changes to data sensitivity levels, when necessary.

IMPORTANT: You are instructed to classify data more sensitive than this guide, if you feel that is warranted by the content.

Internal Use

Confidential

Restricted
Data
Sensitive Data Elements
Class

Public
Social Security Number (SSN) X
Employer Identification Number (EIN) X
Driver’s License (DL) Number X
Client or Employee Personal Data

Financial Account Number X

Payment Card Number (credit or debit) X
Government-Issued Identification (e.g., passport, permanent resident card, etc.) X
Controlled Unclassified Information (CUI) X
Birth Date X
First & Last Name X
Age X
Phone and/or Fax Number X
Home Address X
Gender X
Ethnicity X
Email Address X
Compensation & Benefits Data X
Related Data
Employee-

Medical Data X
Workers Compensation Claim Data X
Education Data X
Dependent or Beneficiary Data X
Business Plan (including marketing strategy) X
Marketing

Financial Data Related to Revenue Generation X

Sales &

Data

Marketing Promotions Development X

Internet-Facing Websites (e.g., company website, social networks, blogs, promotions, etc.) X
News Releases X
Username & Password Pairs X
Public Key Infrastructure (PKI) Cryptographic Keys (public & private) X
Infrastructure Data
Networking &

Hardware or Software Tokens (multifactor authentication) X

System Configuration Settings X
Regulatory Compliance Data X
Internal IP Addresses X
Privileged Account Usernames X
Service Provider Account Numbers X
Corporate Tax Return Information X
Financial Data Financial Data

Legal Billings X
Strategic

Budget-Related Data X
Unannounced Merger and Acquisition Information X
Trade Secrets (e.g., design diagrams, competitive information, etc.) X
Electronic Payment Information (Wire Payment / ACH) X
Operating

Paychecks X
Incentives or Bonuses (amounts or percentages) X
Stock Dividend Information X
Bank Account Information X

NIST Cybersecurity Framework WISP - Version 2018.1 Page 86 of 112

APPENDIX D: BASELINE SECURITY CATEGORIZATION GUIDELINES

Assets and services are categorized by two primary attributes: (a) the potential impact they pose from misuse and (b) the data
classification level of the data processed, stored or transmitted by the asset or process. These two attributes combine to establish
a basis for controls that should be assigned to that system or asset. This basis is called an Assurance Level (AL).

D-1: DATA SENSITIVITY

This is straightforward where the data sensitivity rating represents the highest data classification of the data processed, stored or
transmitted by the asset or process

D-2: SAFETY & CRITICALITY

The Safety & Criticality (SC) rating reflects two aspects of the “importance” of the asset or process:
 On one hand, SC simply represents the importance of the asset relative to the achievement of the company’s goals and
objectives (e.g., business critical, mission critical, or non-critical).
 On the other hand, SC represents the potential for harm that misuse of the asset or service could cause to ACME, its clients,
its partners, or the general public.

The three (3) SC ratings are:

 SC-1: Mission Critical. This category involves systems, services and data that is determined to be vital to the operations or
mission effectiveness of ACME:
o Includes systems, services or data with the potential to significantly impact the brand, revenue or customers.
o Any business interruption would have a significant impact on ACME’s mission.
 Cannot go down without having a significant impact on ACME’s mission.
 The consequences of loss of integrity or availability of a SC-1 system are unacceptable and could include
the immediate and sustained loss of mission effectiveness.
o Requires the most stringent protection measures that exceed leading practices to ensure adequate security.
o Safety aspects of SC-1 systems, services and data could lead to:
 Catastrophic hardware failure;
 Unauthorized physical access to premises; and/or
 Physical injury to users.
 SC-2: Business Critical. This category involves systems, services and data that are determined to be important to the support
of ACME’s business operations:
o Includes systems, services or data with the potential to moderately impact the brand, revenue or customers.
o Affected systems, services or data can go down for up to twenty-four (24) hours (e.g., one (1) business day) without
having a significant impact on ACME’s mission.
 Loss of availability is difficult to deal with and can only be tolerated for a short time.
 The consequences could include delay or degradation in providing important support services or
commodities that may seriously impact mission effectiveness or the ability to operate.
 The consequences of loss of integrity are unacceptable.
o Requires protection measures equal to or beyond leading practices to ensure adequate security.
o Safety aspects of SC-2 systems could lead to:
 Loss of privacy; and/or
 Unwanted harassment.
 SC-3: Non-Critical. This category involves systems, services and data that are necessary for the conduct of day-to-day
operations, but are not business critical in the short-term:
o Includes systems, services or data with little or potential to impact the brand, revenue or customers.
o Affected systems, services or data can go down for up to seventy-two (72) hours (e.g., three (3) business days)
without having a significant impact on ACME’s mission.
 The consequences of loss of integrity or availability can be tolerated or overcome without significant
impacts on mission effectiveness.
 The consequences could include the delay or degradation of services or routine activities.
o Requires protection measures that are commensurate with leading practices to ensure adequate security.
o Safety aspects of SC-3 systems could lead to:
 Inconvenience;
 Frustration; and/or
 Embarrassment.

NIST Cybersecurity Framework WISP - Version 2018.1 Page 90 of 112

Where the data sensitivity and SC levels meet is considered the Assurance Levels (AL). The AL represents the “level of effort” that is
needed to properly ensure the Confidentiality, Integrity, Availability and Safety (CIAS) of the asset or process.

Asset Data Sensitivity

Categorization INTERNAL
RESTRICTED CONFIDENTIAL PUBLIC
Matrix USE

SC-1
Enhanced Enhanced Enhanced Enhanced
Mission Critical
Criticality
Safety &

SC-2
Enhanced Enhanced Basic Basic
Business Critical

SC-3
Enhanced Basic Basic Basic
Non-Critical
Figure D-1: Asset Categorization Risk Matrix

D-3: BASIC ASSURANCE REQUIREMENTS

 The minimum level of controls is defined as industry-recognized leading practices (e.g., PCI DSS, NIST 800-53, ISO 27002,
etc.).
 For security controls in Basic assurance projects or initiatives, the focus is on the cybersecurity controls being in place with
the expectation that no obvious errors exist and that as flaws are discovered they are addressed in a timely manner.

D-4: ENHANCED ASSURANCE REQUIREMENTS

 The minimum level of controls is defined as exceeding industry-recognized leading practices (e.g., DLP, FIM, DAM, etc.).
 For security controls in Enhanced Assurance projects, it is essentially the Basic Assurance level that is expanded to require
more robust IT security capabilities that are commensurate with the value of the project to ACME.

NIST Cybersecurity Framework WISP - Version 2018.1 Page 91 of 112

ANNEX 1 – CYBERSECURITY POLICIES

CYBERSECURITY GOVERNANCE (GOV)

Management Intent: The purpose of the Cybersecurity Governance (GOV) policy is to specify the development, proactive
management, and ongoing review of ACME’s cybersecurity program.

Policy: ACME shall protect the confidentiality, integrity, and availability of its data and information systems, regardless of how its
data is created, distributed, or stored. Security controls will be tailored accordingly so that cost-effective controls can be applied
commensurate with the risk and sensitivity of the data and information system, in accordance with all legal obligations.

ASSET MANAGEMENT (AST)

Management Intent: The purpose of the Asset Management (AST) policy is to ensure that technology assets are properly managed
throughout the lifecycle of the asset, from procurement through disposal.

Policy: ACME shall protect its assets and data by implementing and maintaining appropriate IT Asset Management (ITAM) business
practices across the enterprise.

BUSINESS CONTINUITY & DISASTER RECOVERY (BCD)

Management Intent: The purpose of the Business Continuity & Disaster Recovery (BCD) policy is to establish processes that will help
ACME recover from adverse situations with the minimal impact to operations.

Policy: ACME shall establish and manage the capability for maintaining the Continuity of Operations (COOP) to ensure the availability
of critical technology resources during adverse conditions.

CAPACITY & PERFORMANCE PLANNING (CAP)

Management Intent: The purpose of the Capacity & Performance Planning (CAP) policy is to prevent avoidable business interruptions
caused by capacity and performance limitations through requiring both technology and business leadership to maintain situational
awareness of current and future performance.

Policy: ACME shall protect against avoidable impacts to operations by proactively managing the capacity and performance of its
critical technology and supporting infrastructure.

CHANGE MANAGEMENT (CHG)

Management Intent: The purpose of the Change Management (CHG) policy is for both technology and business leadership to
proactively manage change. Without properly documented and implemented change controls, security features could be
inadvertently or deliberately omitted or rendered inoperable, processing irregularities could occur, or malicious code could be
introduced. This includes the assessment, authorization, and monitoring of technical changes across the enterprise.

Policy: All technology changes to production environments must follow a standard process to reduce the risk associated with change.
ACME requires active stakeholder involvement to ensure changes are appropriately tested, validated, and documented before
implementing any change on a production network.

COMPLIANCE (CPL)
Management Intent: The purpose of the Compliance (CPL) policy is to ensure safeguards are in place to be aware of and comply
with applicable statutory, regulatory and contractual compliance obligations.

Policy: In accordance with all applicable legal requirements, ACME shall ensure appropriate safeguards are in place to protect
sensitive business data against loss, unauthorized access, or disclosure.

NIST Cybersecurity Framework WISP - Version 2018.1 Page 108 of 112

WRITTEN INFORMATION SECURITY PROGRAM
(WISP)

FORMS, TEMPLATES & REFERENCES

 TABLE OF CONTENTS

WISP IMPLEMENTATION OVERVIEW 3

WISP TEMPLATE 1: MANAGEMENT DIRECTIVE EXAMPLE WORDING 4
WISP TEMPLATE 2: USER ACKNOWLEDGEMENT FORM 5
WISP TEMPLATE 3: USER EQUIPMENT RECEIPT OF ISSUE 6
WISP TEMPLATE 4: SERVICE PROVIDER NON-DISCLOSURE AGREEMENT FORM 6
WISP TEMPLATE 5: INCIDENT RESPONSE FORM 8
WISP TEMPLATE 6: APPOINTMENT ORDERS – INFORMATION SECURITY OFFICER (ISO) 9
WISP TEMPLATE 7: ADMINISTRATOR ACCOUNT REQUEST FORM 10
WISP TEMPLATE 8: CHANGE MANAGEMENT REQUEST FORM 11
WISP TEMPLATE 9: CHANGE CONTROL BOARD (CCB) MEETING DOCUMENTATION TEMPLATE 13
WISP TEMPLATE 10: PLAN OF ACTION & MILESTONES (POA&M) DOCUMENTATION TEMPLATE 14
WISP TEMPLATE 11: PORTS, PROTOCOLS & SERVICES (PPS) DOCUMENTATION TEMPLATE 15
WISP TEMPLATE 12: REGULATORY & NON-REGULATORY COMPLIANCE CHECKLIST 16
WISP TEMPLATE 13: INCIDENT RESPONSE PLAN (IRP) TEMPLATE 17
WISP TEMPLATE 14: BUSINESS IMPACT ANALYSIS (BIA) TEMPLATE 30
WISP TEMPLATE 15: DISASTER RECOVERY PLAN (DRP) & BUSINESS CONTINUITY PLAN (BCP) TEMPLATE 32
WISP TEMPLATE 16: PRIVACY IMPACT ASSESSMENT (PIA) 36
WISP REFERENCE: ELECTRONIC DISCOVERY (E-DISCOVERY) GUIDELINES 38
WISP REFERENCE: REGULATORY & NON-REGULATORY COMPLIANCE GUIDE 39
GRAMM-LEACH-BLILEY ACT (GLBA) 39
SARBANES-OXLEY ACT OF 2002 (SOX) 40
FAIR AND ACCURATE CREDIT TRANSACTION ACT OF 2003 (FACTA) 40
HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT (HIPAA) 41
HIPAA SECURITY RULE 41
SECURITIES & EXCHANGE COMMISSION (SEC) 42
PAYMENT CARD INDUSTRY DATA SECURITY STANDARD (PCI DSS) 43

Written Information Security Program (WISP) – Supplemental Documentation Page 2 of 43

WISP IMPLEMENTATION OVERVIEW

The diagram depicted below is an illustration of the process flow that generally takes place to implement a Written Information
Security Program (WISP) within an organization. There will most likely be some level of customization of the WISP that is
necessary to meet [Company Name]’s unique requirements and staffing levels.

Written Information Security Program (WISP) – Supplemental Documentation Page 3 of 43

WISP TEMPLATE 1: MANAGEMENT DIRECTIVE EXAMPLE WORDING

Written Information Security Program (WISP) Implementation

[Official Company Name] ([Company Name]) is committed to protecting its employees, partners, clients and [Company Name] from
damaging acts that are intentional or unintentional. Effective security is a team effort involving the participation and support of
every [Company Name] user who interacts with data and information systems. The reason for implementing [Company Name]’s
Written Information Security Program (WISP) is not to impose restrictions that are contrary to [Company Name]’s established
culture of openness, trust, and integrity, but to strengthen [Company Name]’s ability to guard against unauthorized access to,
alteration, disclosure or destruction of data and information systems. This also includes against accidental loss or destruction.

The purpose of the Written Information Security Program is to ensure that security controls are properly implemented and that
clients and business partners are confident their information is adequately protected. Protecting company information and the
systems that collect, process, and maintain this information is of critical importance. Therefore, the security of information systems
must include controls and safeguards to offset possible threats, as well as controls to ensure accountability, availability, integrity,
and confidentiality of the data:

 Confidentiality – This security component addresses preserving authorized restrictions on information access and
disclosure, including means for protecting personal privacy and proprietary information.
 Integrity – This security component addresses the property that sensitive data has not been modified or deleted in an
unauthorized and undetected manner.
 Availability – This security component addresses ensuring timely and reliable access to and use of information.

The WISP establishes the foundation for the Information Security Program at [Company Name] . The formation of the policies is
driven by many factors, with the key factor being a risk. These policies set the ground rules under which [Company Name] shall
operate and safeguard its data and information systems to both reduce risk and minimize the effect of potential incidents.

These policies, including their related procedures, standards, and guidelines, are necessary to support the management of
information risks in daily operations. The development of policies provides due care to ensure [Company Name] users understand
their day-to-day security responsibilities and the threats that could impact the company.

Implementing consistent security controls across the company will help [Company Name] comply with current and future legal
obligations to ensure long term due diligence in protecting the confidentiality, integrity, and availability of [Company Name] data.

It is the responsibility of every user to know these policies and to conduct their activities accordingly. The WISP is effective as of
[enter date policy is effective].

Respectfully,

[owner/manager’s signature]
[insert owner/manager’s printed name]
[insert owner/manager’s title]

Written Information Security Program (WISP) – Supplemental Documentation Page 4 of 43

WISP TEMPLATE 2: USER ACKNOWLEDGEMENT FORM

[Official Company Name]

([Company Name])

Written Information Security Program Acknowledgement

I, , acknowledge I have read [Company Name]’s Written Information Security

Program (WISP). I agree to abide by [Company Name]’s policies, standards, and procedures.

I acknowledge that if I do have any questions regarding any information within [Company Name]’s WISP, it is my responsibility to
address those issues with my manager for further clarification. I acknowledge that ignorance on my part is not an excuse and I take
full responsibility for my actions and the actions I fail to do. I acknowledge and understand that failure on my part to practice due
care and due diligence may also result in the termination of my employment for cause.

I agree to indemnify, defend and hold harmless [Company Name] , its subsidiaries and affiliated companies, and each of its respective
owners, officers, directors, managers, employees, shareholders and agents (each an "indemnified party" and, collectively,
"indemnified parties") from and against any and all claims, damages, losses, liabilities, suits, actions, demands, proceedings (whether
legal or administrative), and expenses (including, but not limited to, reasonable attorney's fees) threatened, asserted or filed by a
third-party against any of the indemnified parties arising out of or relating to any and all gross negligence and/or misconduct on my
part.

The terms of this acknowledgment shall survive any termination of employment.

User Name / Title Signature & Date

User’s Supervisor / Manager Signature & Date

Written Information Security Program (WISP) – Supplemental Documentation Page 5 of 43

WISP TEMPLATE 5: INCIDENT RESPONSE FORM

[Official Company Name]

([Company Name])

Incident Response Form

Incident Report

System: Date: Time:

Submitted By: Location:
Submitted To (supervisor’s name):
Description of Problem (Who, What, Where, When, Why, and How)

Damage Assessment

Steps Taken to Restore Service / Remedy Problem

Time Required to Restore Service / Remedy Problem

Resources Used

Changes Requested / Needed to Update Information Security Procedures

Written Information Security Program (WISP) – Supplemental Documentation Page 8 of 43

WISP TEMPLATE 7: ADMINISTRATOR ACCOUNT REQUEST FORM

[Official Company Name]

([Company Name])

Administrator Account Request Form

INSTRUCTIONS
Completed forms should be submitted to your primary supervisor. Your supervisor will forward this to the IT department.

End User Name: Phone:

Department: Email Address:

Type of
 Domain Administrator  Local Administrator  Power User  Other
Rights:

Request
Reason(s):

Requestor Signoff

As the end user specified on this form, I certify that the information provided in this document is both true and accurate.

The end user also recognizes the increased responsibilities inherent to having an account with elevated privileges and will follow
all policies, procedures, standards, and guidelines required by [Company Name] users with administrative rights. Failure to follow
these standards will result in immediate revocation of elevated privileges.

End User Signature X Date: / /

Requestor’s Supervisor

Completed Date
Signature: X / /
By: Received:
(print name)

Information Security Officer (ISO)

Received Signature: X Date / /

By: Received:
(print name)

The expiration date of elevated privileges (if applicable):

Written Information Security Program (WISP) – Supplemental Documentation Page 10 of 43

WISP TEMPLATE 13: INCIDENT RESPONSE PLAN (IRP) TEMPLATE

By the very nature of every incident being somewhat different, the guidelines provided in this Incident Response Plan (IRP) do not
comprise an exhaustive set of incident handling procedures. These guidelines document basic information about responding to
incidents that can be used regardless of hardware platform or operating system. This plan describes the stages of incident
identification and handling, with the focus on preparation and follow-up, including reporting guidelines and requirements.

PLAN OBJECTIVES
The objective of Incident Response Plan (IRP) is to:
 Limit immediate incident impact to customers and business partners;
 Recover from the incident;
 Determine how the incident occurred;
 Find out how to avoid further exploitation of the same vulnerability;
 Avoid escalation and further incidents;
 Assess the impact and damage in terms of financial impact and loss of image;
 Update company policies, procedures, standards and guidelines as needed; and
 Determine who initiated the incident for possible criminal and/or civil prosecution.

INCIDENT DISCOVERY

Malicious Actions Possible Indications of an Incident

Denial of Service
You might be experiencing a DoS if you see…
(DoS) Examples

• User reports of system unavailability

• Unexplained connection losses
• Network intrusion detection alerts
• Host intrusion detection alerts (until the host is overwhelmed)
Network-based DoS
• Increased network bandwidth utilization
against a particular host
• Large number of connections to a single host
• Asymmetric network traffic pattern (large amount of traffic going to the host, little traffic coming from the host)
• Firewall and router log entries
• Packets with unusual source addresses

• User reports of system and network unavailability

• Unexplained connection losses
• Network intrusion detection alerts
Network-based DoS • Increased network bandwidth utilization
against a network • Asymmetric network traffic pattern (large amount of traffic entering the network, little traffic leaving the network)
• Firewall and router log entries
• Packets with unusual source addresses
• Packets with nonexistent destination addresses

• User reports of system and application unavailability

DoS against the
• Network and host intrusion detection alerts
operating system of a
• Operating system log entries
particular host
• Packets with unusual source addresses

• User reports of application unavailability

DoS against an
• Network and host intrusion detection alerts
application on a
• Application log entries
particular host
• Packets with unusual source addresses

Written Information Security Program (WISP) – Supplemental Documentation Page 17 of 43

ESCALATION LEVEL CONSIDERATIONS
Incident Response management must consider several characteristics of the incident before escalating the response to a higher
level. These considerations include:
 Legal requirements for breach notification?
 How widespread is the incident?
 What is the impact to business operations?
 How difficult is it to contain the incident?
 How fast is the incident propagating?
 What is the estimated financial impact of [Company Name] ?
 Will this negatively affect [Company Name]’s image?

INCIDENT RESPONSE PROCESS

The Incident Response Process is an escalation process whereas the impact of the incident becomes more significant or widespread,
the escalation level increases bringing more resources to bear on the problem. At each escalation level, team members who will be
needed at the next higher level of escalation are alerted to the incident so that they will be ready to respond if and when they are
needed.

Responsible
Step Incident Response Plan (IRP) Actions Completed
Entity
Detection and Analysis Phase
1.0 Anyone Determine If an Incident Occurred
1.1 Anyone Analyze the precursors and indications. (Appendix 16-1)
1.2 Anyone Look for correlating information. (Appendix 16-2)
1
1.3 Anyone Perform research (e.g. search engines, vendor knowledge base, peer review, etc.)
As soon as the incident handler believes an incident has occurred, he/she must begin
1.4 Anyone
documenting the incident and gathering evidence.
2.0 Anyone Notify IT Support
2.1 Anyone The incident handler contacts IT Support and provides available documentation and evidence.
2.2 IT Support IT Support classifies the incident according to Appendix 16-1
2
If the IT Support categorizes the event as a full investigation, the IT Support technician should
2.3 IT Support
create a case file.
IT Support on-call analyst consolidates documentation and evidence and, if applicable, stores
2.4 IT Support
the documentation in the case folder for the incident.
3.0 IT Support Incident Prioritization
3.1 IT Support IT Support prioritizes handling the incident based on the business impact.
3 IT Support will identify which IT resources have been affected and forecast which resources
3.2 IT Support
will be affected.
3.3 IT Support IT Support will estimate the current and potential technical effect of the incident.
4.0 IT Support Incident Notification
4
4.1 IT Support IT Support will contact affected asset owners and business units, alerting them to the situation.
5.0 Multiple Entities Incident Escalation (If Required)
If the incident is believed to be significant, the IT Support technician or asset owner is
5 5.1 IT Support
responsible for notifying management for escalation.
5.2 Management Management is responsible for coordinating further incident escalation steps, as required.
Containment, Eradication, and Recovery Phase
6.0 IT Support Secure, Document, Acquire, Preserve & Analyze Evidence (If Required)
6 IT Support will follow its Standard Operating Procedures (SOP) for evidence seizure and
6.1 IT Support
analysis.

Written Information Security Program (WISP) – Supplemental Documentation Page 27 of 43

WISP TEMPLATE 15: DISASTER RECOVERY PLAN (DRP) & BUSINESS CONTINUITY PLAN (BCP) TEMPLATE

DISASTER RECOVERY PLAN (DRP)

A Disaster Recovery Plan (DRP) specifies emergency response procedures, including specifying individual responsibility for
responding to emergency situations and specifying procedures to enable team members to communicate with each other and with
management during and after an emergency.

DRP CLASSIFICATION
Information system criticality and mission importance for the DRP is the same Mission Assurance Category (MAC) levels as defined
in Appendix D: Baseline Security Categorization Guidelines.

DRP SCOPING REQUIREMENTS

The DRP requirements for critical assets are summarized below:

Disaster Recovery Plan (DRP) Summary

Criticality MAC I MAC II MAC III

High security required; must be in High security required; must be in High security required; must be in
Restricted
Disaster Recovery Plan Disaster Recovery Plan Disaster Recovery Plan

Moderate security required; must Moderate security required; may Moderate security required; need
Confidential
be in Disaster Recovery Plan be in Disaster Recovery Plan not be in Disaster Recovery Plan
Data
Sensitivity
Minimal security required; must be Minimal security required; may be Minimal security required; need
Internal Use
in Disaster Recovery Plan in Disaster Recovery Plan not be in Disaster Recovery Plan

Minimal security required; must be Minimal security required; may be Minimal security required; need
Public
in Disaster Recovery Plan in Disaster Recovery Plan not be in Disaster Recovery Plan

Backup copies of data and software that are sufficient for recovery from an emergency situation pertaining to critical assets must
be stored at a secure, external site providing standard protection against hazards such as fire, flood, earthquake, theft, and decay.
Requirements and procedures for such offsite backup shall be included in the DRP, including procedures and authorities for
obtaining access to such sites in the event of an emergency.

Disaster recovery requirements should be specified when establishing maintenance agreements with vendors supplying
components of critical resources. Ensure that vendors can provide replacement components within a reasonable period of time
when planning system upgrades or deployments.

DATA BACKUP AVAILABILITY

Backup copies of data and software must be sufficient to satisfy DRP requirements, application or other critical information asset
processing requirements, and any functional requirements of any critical information asset custodian dependent upon such data.
Backup copies for disaster recovery purposes must be stored at a secure, off-site location that provides industry-standard
protection. These backup requirements extend to all information systems and data necessary to be reconstituted in the event of a
disaster.

Written Information Security Program (WISP) – Supplemental Documentation Page 32 of 43