3.2 Explain the purpose of organizational documents and policies

  • Plans and Procedures
    • Change Management
    • Incident Response Plan
    • Disaster Recovery Plan
    • Business Continuity Plan
    • System Life Cycle
    • Standard Operating Procedures
  • Hardening and Security Protocols
    • Password Policy
    • Acceptable Use Policy
    • Bring Your Own Device (BYOD) Policy
    • Remote Access Policy
    • Onboarding and Offboarding Policy
    • Security Policy
    • Data Loss Prevention
  • Common Documentation
    • Physical Network Diagram
      • Floor Plan
        • Rack Diagram
        • Intermediate Distribution Frame (IDF) / Main Distribution Frame (MDF) Documentation
    • Logical Network Diagram
    • Wiring Diagram
    • Site Survey Report
    • Audit and Assessment Report
    • Baseline Configuration
  • Common Agreements
    • Non-Disclosure Agreement (NDA)
    • Service-Level Agreement (SLA)
    • Memorandum of Understanding (MOU)

A policy tells users how to what actions to take in each situation so that they are not guessing.  Some policies that might apply to networks include

  • Change Management – Change Management is the process for managing changes to assets and systems.  Change management is also known as configuration management. 

    In a large organization, a single employee cannot make a change on his own.  For example, an IT technician can’t just decide to change all the Cisco routers to Juniper routers without getting permission.

    Changes cost money, and changes affect other parts of the organization both in the short-term and the long-term.  It is important to document each change so that others can be aware of it in the future.

    Before implementing a change, we must seek approval from a committee, which may be known as the Change Control Board.  The CCB decides whether a change is approved or denied. 

    If it is approved, the CCB ensures that the employee who performs the change does so in accordance with the organization’s policies.  When the change is complete, the CCB documents the change. 

    If it is denied, the CCB will document the reasons for denying the change.

    An organization will have policies for who must approve each type of change depending on what it affects and the level of risk.  For example, a change that presents a low-level risk may require approval from the department head, and a change that presents a high level of risk may require approval from the CEO.

In an IT environment, change management applies to network hardware configuration, switch configuration, security policies, the physical location of infrastructure, and many other items. 

Some of the things that might require a change management procedure

  • Replacing a piece of network equipment (switch, router, wireless access point)

    • Change in the configuration of a piece of network equipment

    • Installation of a new network cable drop

    • Installation of a new internet connection
    • Installing new network cable drops

  • Incident Response Plan – An Incident is an event that is not normal and that causes disruptions.  For example, the failure of an internet connection or a security breach is considered an incident.  An organization must maintain an Incident Response Plan that is reviewed and practiced regularly.  The plan will include:

    • Documented Incident Types/Category Definitions

      • The organization should maintain a list of different types of incidents and categorize them based on the business lines that they affect

      • The plan should allow a user to determine the severity of an incident (Critical, Serious, Minor, etc.) based upon its impact to the business, human life, clients, etc.

      • Each category and severity should have a standard response procedure

      • It should state who is notified in each scenario (executives, customers, government agencies, 911)?

      • It should state the people who will be involved in the incident response and describe the role of each one

    • Why do we do this?  When an incident occurs (and incidents will occur!), we don’t have to panic.  We categorize the incident based on its severity and impact, and then we follow the appropriate procedure.

    • Roles and Responsibilities

      • Each department is specifically tasked with a responsibility for each incident category

      • When an incident occurs, a team composed of each departments’ representatives is summoned.  Each person on the team will have reviewed the plan and knows exactly what to do.

    • Reporting Requirements/Escalation

      • We use the plan to determine the response, if any

      • Does the organization have to respond to the incident at all?  Do they have to report the incident to a higher level in the organization (vice president, CEO, board of directors, shareholders, etc.)?  This depends on

        • The severity of the incident

        • How long it takes to resolve the incident

        • The impact to the business and its customers

        • Organization may have to report the incident to the government if it involves a

          • Data leak

          • Chemical spill

          • Public health matter

          • Contamination of a food product or pharmaceutical

    • Cyber-Incident Response Teams

      • An organization may maintain a Cyber Incident Response Team that is dedicated to responding to a cyber incident.  This team may travel to the physical of the incident or work remotely.

      • Other third parties also have cyber response teams.  We might choose to outsource our incident response to a third party that is more experienced, especially when it involves a security breach or when we require an independent investigation.  The FBI has a cyber response team that can deploy to any cyber incident location within 48 hours.

    • Exercise

      • It is impossible to know how a person will react to a real crisis until it happens.  Nevertheless, the organization should practice its response to each type of incident on a regular basis.  The more people practice, the better they will respond when the crisis occurs.

      • No plan ever failed on paper.  The exercise also allows an organization to identify errors that made it through the planning phase.

      • After a real incident, the organization should evaluate its response and modify the plan accordingly.

  • Disaster Recovery Plan – A disaster recovery plan allows the organization to resume normal operations after a discovery.

    • What is a disaster?  A disaster is a serious event that causes grave disruption.  It could include a natural event like a fire, flood, earthquake or hurricane.  It could also include a man-made event like a war or an industrial accident.

    • Our disaster recovery plan should

      • Consider all the different causes of disruption that affect our operations in each geographic area.  For example, an organization located in Florida should consider hurricanes, but an organization in Wyoming should not.

      • Identify the amount of downtime the organization can accept before having to resume normal operations.  An organization such as an insurance company may not accept any disruption to its operations.  A retail store may accept a disruption of one or two weeks.  The shorter the disruption, the more expensive the recovery plan.

      • Specifically state the sources of vendors, equipment, parts, and supplies that are required to implement the recovery.

      • Describe the roles of each person who will assist with the disaster recovery effort.

      • For example, if a fire in our server room occurs, our disaster recovery plan might include the following

        • Contacting the insurance company to file a claim

        • Salvaging any available equipment or materials

        • Construction of a server room, either in the same location or in a new location

        • Installation of new equipment and of salvaged equipment

        • Testing equipment

        • The people who would be involved

          • Accountant to mange the budget and file the insurance claim

          • Project manager to oversee the new construction

          • Engineer or architect to provide advice regarding applicable building codes

          • Procurement to obtain new equipment

          • Network technicians to configure and install the new equipment

  • Business Continuity Plan – A business continuity plan allows the organization to continue operating in the event of a disaster.  We can combine the Business Continuity Plan and the Disaster Recovery Plan so that our business can keep operating while working to get back to normal operations.

    • The number one rule is to not let people panic, but most people forget about this.  It is more important than fixing the actual problem.  When people panic, they behave irrationally, and things get worse.

    • What does the plan include?

      • We first must cut up the organization into different departments and decide which ones are crucial

      • We must also look within each department to determine whether the entire department is critical or whether a subset of its employees is critical

      • We must then determine the types of disasters that can affect each organization.  We could possibly make a table, where roles are columns and disasters are rows.  Then each cell would be a plan.

      • Ask the following questions

        • If the disaster causes the person in that specific role to die or get injured or otherwise become unavailable, how can we replace them?  Are there other employees in the department who are trained to perform in that person’s role?  Or are there contractors who can?

        • If the disaster affects the person’s workspace, can the person work from home?  Does the person have adequate equipment to do their job from home?

        • Does the company have other offices where it can carry out the same functions?

        • Can customers interact with the company remotely?

    • For example, say we manufacture toilet paper.  We might have the following roles

      • People who operate the manufacturing equipment.  Some people add raw pulp to the mixing machines.  Some people operate the packaging machines.  Some people operate the forklifts, etc.

        • We can’t shut down the manufacturing plant and people can’t work from home.  People can’t make toilet paper at home.

        • If the plant is damaged by a natural disaster, we cannot continue operating unless we had a second manufacturing plant in another region.  Distributing our critical operations is a good idea, but if the business is small, it might not be possible or efficient.

        • We might be able to run the plant with fewer workers than we have (for example if many workers must quarantine due to an illness)

        • We should document the role of each person so that it is easier to train a new person to fill their role.  Sometimes people keep the knowledge in their heads and not on paper.

      • People who purchase materials

        • People who purchase materials can work from home

      • People who maintain the manufacturing equipment

        • People who maintain the manufacturing equipment are critical, just like those who operate them, but it is possible that a contractor could perform their task

      • People who sell toilet paper to stores

        • Sales people are important, but the business can continue to serve existing customers until they recover

        • Sales people can work from home

      • People who deliver toilet paper to stores

        • Delivery services can be outsourced to a contractor

      • Management

        • Management can work from home

        • If a manager dies, we might be able to have another manager step into their role.  That means we should have the managers trained to understand the entire business.

      • Financial people who pay bills and invoice customers

        • Financial people can work from home

    • The organization should practice the disaster recovery plan and business continuity plan, holding regular drills with the key responders.

    • The organization should review and revise the plans to take advantage of new technologies and consider new threats.

    • The more effective the disaster recovery plan, the more it will cost.  The disaster recovery plan may cost the organization, even when no disaster has taken place.  For example, maintaining a second office for emergency use may cost the organization tens of thousands of dollars per month.  Is the potential harm caused by the disaster (multiplied by its likelihood) more expensive than the cost of maintaining the office?  The organization must decide about the types of risks that it is willing to accept.

    • With respect to networks, the focus is on

      • How do we make sure that the data is secure and accessible (i.e. not permanently lost during a disaster)?

        • Is the data backed up to multiple sources?

      • How do we make sure that the users can continue to connect to the network and access their software?

        • Do we have spare network equipment, redundant power, cooling, etc.?

        • Do we have documentation of the network, how it is configured, and how everything is connected?

        • Have we documented all of the vendors that need to be notified (electrical, HVAC, internet, networking, servers, etc.)?

        • Which pieces of network equipment are critical and which ones are not?

  • System Life Cycle – A system life cycle outlines how long a component remains in the organization, how it is introduced, and how it is removed.  It usually consists of the following phases

    • Investigation/Design – in this phase, we consider the requirements of the component.  We then decide what the best component is for the job.  For example, if we want to purchase a switch, we would look at

      • The makes and models of switches available.  We might have to select from an approved vendor.

      • Whether we require a 24-port switch, a 48-port switch, or multiple switches

      • Whether we require a switch that supports SFPs, Gigabit Ethernet, 10G Ethernet, etc.

      • Whether we require a layer 2 or layer 3 switch

      • The budget of the organization

      • The time frame for purchasing the switch

      • Who will configure the switches

      • Where the switches will be installed

    • Installation – once we have purchased the component, we must install it.  We might use the Change Management to obtain approval for the installation.  We should obtain approval prior to expending funds (in case the change is rejected).  We might also use a standard operating procedure.  For example, we have now purchased the switch

      • We set up a date and time to replace the existing switch

      • We ensure that we have a valid configuration for the new switch

      • We assign a technician to replace the switch and configure the new switch

      • The old switch is decommissioned

    • Operational – the item is now in use.  We must identify how long the item will last in our organization.  There are five possibilities

      • The item will continue to function until it fails.  This is common with items that fail quickly due to the harsh environment, items that are low cost, or items that are obsolete. 

        For example, we might allow the coffee maker or microwave to run until it fails.  It can be replaced quickly and with little disruption to the business.  We do not want to allow a router or other critical network component to run until it fails. 

        We might have a local server that is being replaced by a cloud device but want to maximize our cost savings.  If the failure of the local server does not cause disruptions, we might allow it to operate until it fails.

      • The item will last a specific period.  This is common with items that wear out after some time, or items that present a safety risk when they fail.

        For example, many organizations specify that their laptops or desktops are replaced every three or four years.  When a laptop is three years old, it must be replaced with a newer model.  This reduces the risk of a failure (which could be expensive).  It also reduces maintenance costs associated with repairing old laptops.  It also ensures that users have access to the latest technology.

        We should replace critical safety equipment such as hard hats, steel toed boots, and safety harnesses well before they could be expected to fail. 

      • The item will last until newer technology is becomes available.  For example, we might specify that switches with 10/100 ports are to be replaced with Gigabit switches.  We might not want to replace Gigabit switches with 10 Gigabit switches until the cost is low enough.

      • The item will last until it wears out. 

        For example, we replace vehicle tires once they are worn out.  It is based on the depth of the tread, not the age of the tire.  Electronics usually fail catastrophically, not gradually, but some devices start to overheat as they age.  We might replace a device once it becomes prone to overheating.

      • The item is no longer required.  The organization has decided that it no longer wants to use this item.  For example, the organization has switched from Cisco routers to Juniper routers.  The Cisco router is still functional, but the organization no longer wants to use it.

    • Decommission – we remove the item from service.  The item has reached the end of its useful life, it has failed during operation, or it is no longer required.  We should start the planning phase for the replacement well ahead of time so that the new item is available.

      The decommission phase must also include disposing of the old item and wiping any sensitive data from it.

  • Standard Operating Procedures – A Standard Operating Procedure a set of instructions for common tasks that an organization performs.  Employees, vendors, and contractors are required to follow standard operating procedures when those procedures exist.  A standard operating procedure is designed to reduce risk, reduce uncertainty, and improve safety.  A large organization may have many different procedures for things like

    • Climbing a ladder

    • Operating a company vehicle

    • Booking travel

    • Obtaining a corporate credit card

    • Paying an invoice

    • Issuing a purchase order

IT Standard Operating Procedures can exist for

  • Creating new user accounts

    • Disabling terminated user accounts

    • Acquiring software and hardware

    • Replacing network equipment

Standard Operating Procedures are based on laws and security practices.  An organization will revise the procedures when they acquire new information about risks.

Some policies that apply specifically to information technology ideas

  • Password Policy – a password policy may include the following

    • A statement that users should not share passwords or write them down

    • How often a user should change his password

    • Password complexity requirements (number of characters, special characters, numbers, etc.)

    • How many times a password must be changed before it can be reused

    • Whether an account is locked out after the password has been entered incorrectly, and how many incorrect tries are permitted

    • Whether an account must use two-factor or multi-factor authentication

  • Acceptable Use Policy – the Acceptable Use Policy (AUP) describes what the user may do and what they may not do while on a company’s system.  The user may be an employee, contractor, or guest.  In general, the user should

    • Only use the computing resources for purposes that benefit the employer (a guest may not be subject to this restriction)

    • Not use the computing resources for illegal purposes

    • Not access games, social media, pornography, or racist content

    • An employer may allow an employee to use the devices for non-commercial purposes if the impact to the business is minimal (this is a work life balance choice that the employer may make).  For example, a user may be permitted to access social media on their work computer during their lunch break.

    • The AUP must clearly state that the employer’s systems are subject to monitoring and recording, and that the employee has no reasonable expectation of privacy.  In the event the employee is terminated for violating the AUP, the employee will not be able to exclude evidence of wrongdoing in a wrongful termination lawsuit.

    • The employer’s computer systems should clearly state that the system is subject to monitoring and recording.

  • Bring Your Own Device (BYOD) Policy – A BYOF Policy permits each employee to bring their own personal device (subject to restrictions) and connect it to the corporate network. 

    • With BYOD, an employee can use their own personal device and not have to carry two devices.  They can use a device that they like.

    • The organization must be able to provide technical support for a wide range of manufacturers and models.  The organization may limit the support that they provide for BYOD devices to only basic technical support.

    • The organization must be able to ensure that all employee-owned devices can be secured.  They may do this with special software that allows the employer to remotely lock or wipe the device.  Increasingly, they also use software that can separate the employer’s data from the employee’s data.

    • There may be legal restrictions on what the organization can do with an employee-owned device (such as GPS tracking, data erasing, encryption). 

    • The organization may be required to reimburse employees for the use of their phones.

  • Remote Access Policy – The Remote Access Policy determines which users have access to the employer’s system, and how they may access the system.  Both employees and contractors may have access.  The policy should describe

    • Which people have access to the remote network

    • What resources each user has access to.  A user should only have access to the specific resources that they require to perform their job.

    • Whether specific resources are not accessible remotely

    • How a user can access the network.  Do they use a web-based application, or a VPN?  Different applications can have different types of access.

    • Whether the user must use a username/password, a smart card, or multi-factor authentication to access the network

    • Whether the user may access the network through a personal device

  • Onboarding and Offboarding Policy – Onboarding refers to hiring an employee and offboarding refers to firing an employee.  The Onboarding Policy should include

    • Creating the user’s accounts (including the user’s e-mail account)

    • Assigning the user devices such as a desktop, a laptop, a telephone, and a mobile phone

    • Setting up the user’s devices

    • Assigning appropriate privileges to the user based on his role

    • Training the user regarding security precautions and the use of the electronics

    • Ensuring that the user signs the acceptable use policy and is aware of the employer’s policies regarding the use of technology

The Offboarding Policy should include

  • Disabling the user’s account (the user’s account should be disabled prior to informing the user about his termination; otherwise, a disgruntled user may attempt to delete data or cause other damage to the network)

    • Instructing the user to return his company-owned devices

    • Deleting employer data from any employee-owned devices

    • Forwarding the user’s email to another user, and creating an auto-responder to inform senders that the user is no longer employed

    • An exit interview to remind the user of his obligation to keep the employer’s data confidential

Onboarding and Offboarding can be trigged automatically from a request made by the Human Resources department when a user is hired or terminated.

  • Security Policy – The Security Policy describes how the organization keeps its infrastructure secure.  A good approach to security includes multiple layers.  It should include

    • A description of which users have access to each type of resources

    • The type of physical security measures in use at each facility (for example, security guards, cameras, biometric readers, etc.)

    • How the organization handles security breaches (how security breaches are reported, how security breaches are investigated)

    • The type of encryption in use on each device

    • How network devices are configured to prevent unauthorized access

    • How devices are secured to prevent local access to unauthorized users

  • Data Loss Prevention – The Data Loss Prevention policy tells us how we keep the company data from leaving the organization.  It should be noted that most data leaves the organization through the brains of the employee.  It should include

    • The types of data that are considered sensitive, and who has access to each type

    • Whether there are specific legal requirements that require the organization to protect some types of data (for example health data or client personal information)

    • Whether data is encrypted in transit and/or at rest

    • Whether a data leak prevention appliance or other applications is installed and how it is configured

    • Whether users are permitted to copy data to personal devices, to mobile devices, or to portable devices such as USB drives

    • Whether attempts to access specific types of data is logged and/or monitored

    • How the organization investigates and reports data leaks

    • How long does the organization need to store data

We should create some documents and update them each time a change is made.  Documents should be available electronically and on paper.

  • Physical Network Diagram – The Physical Network Diagram shows us where things are located.

    • Floor Plan – the floor plan shows how rooms are arranged and includes

      • Location of network outlets

      • Pathways of the ethernet and fiber optic cables and cable trays/cable support system

      • Location of the IDFs and MDF

      • Location of devices such as wireless access points, cameras, and access control system devices

    • Rack Diagram – a rack diagram shows us each device and what rack unit it is installed in.  A rack diagram is a physical representation of the rack and a paper copy should be in each server room.  It should include

      • The name and description of each device in the rack

      • The physical rack unit that the device is installed in

      • How the device connects to other devices

      • How the device connects to power (and which power outlet on a PDU it connects to)

    • IDF and MDF Documentation – each IDF and MDF should have documentation that includes

      • A Rack Diagram of each rack installed in the room

      • User manuals for each device installed in the room

      • Instructions for maintaining other devices in the room such as the UPS and air conditioner

  • Logical Diagram – a logical diagram is one that shows how devices are connected.  For example, it might show that router port 1 is connected to switch port 48, or that access point 4 is connected to switch port 8.  The logical diagram might also show the different VLANs configured and the and IP addresses of each device.  We can use a logical diagram to connect devices, but it does not show where the wiring is physically located.

  • Wiring Diagram – a wiring diagram shows the physical location of the wiring.  It includes the physical location of network outlets and cable support systems such as conduit and pull boxes.

  • Site Survey Report – a site survey report is a document that is prepared after a site survey.  A site survey is a review of the building conditions to identify features such as wall types, ceiling types, dimensions, outlet locations, wiring locations, etc..  We might complete a site survey prior to installing network equipment; this will allow us to determine whether the building conditions are adequate.  We might also complete a site survey prior to moving in to a new facility. 

    Site surveys are commonly completed prior to installing Wi-Fi.  A wireless site survey tells us the type of walls in the facility and whether they will block or reduce the wireless signal.

  • Audit and Assessment Report – the audit report describes whether the organization is in compliance with a policy.  The report shows us the areas where we are compliant and the areas where we need improvement.  The report might contain recommendations for improving the deficiencies.  The report might be created internally, prepared by a third-party contractor, or prepared by a government organization.  We should maintain a copy of the report so that we can keep track of improvements.

    For example, we might conduct an audit of the organization’s security policy.  The report might indicate that we have excellent surveillance camera coverage but that some doors were propped open. 

  • Baseline Configuration – the baseline shows us how devices are configured and what level they normally operate at.  We can compare the actual state of the devices to the baseline to determine whether our system is operating correctly.  For example, if the baseline


Some Common Agreements we can expect to see in an organization

  • Non-Disclosure Agreement (NDA) – An NDA is a Non-Disclosure Agreement.  Each employee, contractor, or vendor with access to any sensitive data must read and sign the Non-Disclosure Agreement prior to being provided with access to any data.  The NDA may be revised from time to time.  The NDA contains the following features

    • Prohibits employees from disclosing any sensitive data to any person outside the organization

    • Identify how the organization marks sensitive data

    • Describes how the employee should store sensitive data (encrypted USB, laptop, not taking data home, use of personal mobile devices

    • The NDA may have exceptions for legal reasons such as in response to a court order or other legal process

    • Describes how an employee should report the inadvertent disclosure of sensitive data

    • The obligations under the NDA do not stop when the employee leaves the organization

  • Service Level Agreement (SLA) – A Service Level Agreement details the required level of performance and penalties for not meeting those levels.  For example, if an organization purchases web hosting services, the hosting company may guarantee that services will operate 99.99% of the time.  If the web hosting is available less than 99.99% of the time, the organization may be entitled to a refund.  The SLA holds the service provider accountable because downtime costs the organization money. 

    An SLA is typically signed by the organization and a vendor, but an SLA can be created between the organization and the IT department.  This ensures that the IT department’s objectives are aligned with those of the business. 

    The SLA could include

    • Response time for different issues, depending on their impact and priority.  For example, two business day response for non-critical issues, one-hour response time for critical issues

    • Uptime guarantee for web hosting, servers, internet connections, and other services

    • Geographical location where the SLA applies.  For example, urban locations may have a two-hour response time, while rural/remote locations could have a two-day response time

    • Penalty for not meeting the response time or uptime guarantee.  The penalty could be structured as

      • A refund of 10%, 25%, or 100% of the monthly fee paid for a service outage exceeding 1%, 2%, or 5%.  This structure is common for web hosting and cloud compute service providers.  An outage of more than 5% would not typically entitle the customer to a larger refund, but the customer may reconsider using that particular vendor.

      • A penalty for each violation.  The service provider could be required to pay a penalty for each violation.

      • The service provider could be required to reimburse the customer for actual damages caused by the outage.  This not a typical structure because most agreements prohibit indirect or consequential damages.  The service provider’s liability is typically limited to the fees paid by the customer.

  • Memorandum of Understanding (MOU) MOU – An MOU is a general document that outlines the reasons that two parties have for pursuing an agreement (i.e. how each party will benefit from the agreement).  It is not an actual agreement, but it provides a framework for further negotiations.  We might sign an MOU when we are negotiating the purchase of a WAN or a large amount of computer equipment.  Once the MOU is in place, then the parties can negotiate more detailed terms. 

    In the event of a dispute in a formal agreement signed after the MOU is created, a court may look at the original purpose outlined by the MOU, but an MOU is generally not legally binding