top of page
  • Writer's picturegvalyou

Project Security - Often Overlooked Until There's An Issue

Project Security is an often overlooked area on many technology projects. Organizations have become better and better at securing a delivered solution, but the journey to that point is often uncoordinated and inadequate when compared to the level of risk.

Over years of reviewing organizational project processes, software release checklists, individual projects, software and meeting many project managers we have found project security just doesn’t receive the spotlight it deserves and demands. In today’s fast paced, data driven, highly connected and ever changing environments with team members often dispersed all over the world there are many opportunities for project security to fall through the cracks.

The costs of security issues can be high, they can damage a company or brands reputation and have financial repercussions from leaked intellectual property, loss of customers, liability or fines. A recently completed study by IBM found the average consolidated total cost of a data breach is $3.8 million representing a 23% increase since 2013 (1). The Privacy Rights Clearinghouse, a California nonprofit corporation, reports that since 2005 over 895,533,728 records have been breached from 4,717 data breaches made public (2)

Many security issues could have been prevented with some upfront planning, communication and training. As the old adage goes, “an ounce of prevention is better than a pound of cure.”

What Could Go Wrong?

Security issues created during a project are often not as complex or clandestine as most would think, many were created because of a project’s lack of security focused education, processes and controls.

  • An unprotected laptop or phone is lost or left somewhere

  • Project documentation is accessed from an unsecure network in a coffee shop

  • Passwords are written down, lost or shared

  • A team member has a phone call about a new project for a major software company on the subway and the conversation is posted to a well-known video sharing service by an eavesdropper

  • An email containing the specifications for a hot new product is sent to the wrong person outside of the organization by accident and the specification is not password protected

  • During testing a data file containing personal identifiable information or PII (social security number, name and address) of a real customer or employee is exposed on the internet

  • A terminated team member destroys important work product and there is no back up

  • Someone gossips or shares the personal information contained within a test data file on social media

  • Personal email is used by a team member and hacked into

  • During development a back door is created within an application

  • Team members leave the project or are terminated and still have project access

  • Usernames and passwords created for testing are not cleared out of a system when it went live

  • A conference line is used without a password or access code

  • Project work product is stored in a personal unsecured cloud provider

  • A key contract developer goes to a competitor and has no restriction on providing intellectual property

  • Outdated development techniques or technologies are utilized

  • A team member with little technical experience bypasses organizational procedures and sets up their own unsecure development server

Project security responsibilities can vary depending on the industry, size and structure of the organization. In smaller companies it may be an individual project manager’s sole responsibility to ensure the resources perform in a secure manner and that deliverables meet a level of security. In larger organizations there may be policies and procedures created and maintained by divisions under the leadership of a Chief Information Security Officer (CISO), Chief Information Officer, Human Resources Department or a Project Management Office that define the project manager’s level of responsibility.

Regardless of scope of responsibility, Project Managers can help ensure their projects are delivered in a secure manner. A project manager should be able to answer the following questions as they relate to project security:

  • What needs to be secured and why?

  • What is the risk and potential cost in not securing?

  • Who is responsible for ensuring compliance?

  • Who is responsible for communicating security requirements?

  • What is the plan or steps and their impact (actions, timing, resources, effort and costs) for securing a project?

  • How will we test security?

  • Who must approve or have input into the plan?

  • How will plan compliance be verified?

  • If there is an incident or issue during a project what must be done?

  • What is the transition plan for any delivered solution at project completion?

The following steps and examples provide some considerations for a technology project to jump start the thought process around project security. These suggestions may also help identify areas where organizational or project delivery processes should be created if missing.

Step One - Identify

Review any existing Organization, Department Level or Project Management Office security guidelines or processes ensuring they are incorporated into the project. For the core areas to follow, identify any security risk, requirement or need. Remember, organizations and projects are unique and the list should be adjusted accordingly.


To work on the project in any manner, what do contributing Team Members need to complete or be educated on from an Human Resources, Legal or Administrative perspective.


  • Background Checks

  • Fidelity Bonding

  • Security Clearance

  • Non-Disclosure Agreements

  • Personally Identifiable Information and Safe Data Handling Policies and Procedures

  • Compliance Training (HIPAA, FISMA, etc.)


The approved communication methods and guidelines for communication on the project.


  • Email (No Personal Email, Encrypted Email, etc.)

  • Texting

  • Video

  • Screen Sharing

  • Collaboration

  • Conference Lines

  • Social Media

  • Public Question Posting (Blogs, Support Sites)


Devices that can and can’t be used on the project and the approval process or requirements to ensure they meet the prerequisite level of anti-virus, malware, encryption and other device security policies.


  • Computers, Laptops, Tablets

  • Approved Cell Phones

  • Portable USB Devices

Technical Infrastructure and Environments

The technical environments and major infrastructure the project will progress through and team members are required to work in.


  • Sandbox, Development, Test, Production Environments

  • Local Development Environments

  • Network access vehicles including VPN or other access to project work product (code, documents) or managed services (email, applications etc.)

  • Data Storage

  • Back Up Locations and Procedures

  • Public or internet facing components

  • Internet Access

Access Ledgers and Logs

Who is granted access to what information, for how long and how is access tracked.


  • Resource Ledger (Who, What, When, How)

  • Data (Does data sending, receipt, storage or movement have to be logged at any point)

  • Tools and Software

  • Check In and Out of Code or Technical Work Product

  • Documentation

Application and Software

What software or tools can and will be utilized on the project and who is responsible to provide approved access.


  • Operations Tools (Communications, Productivity)

  • Development Tools (Testing, Database, Coding or Development)

  • Coding Best Practice

  • Technical Standards (Security Technical Implementation Guides (STIGs) and the NSA Guides)

Data and Reports

What data will be leveraged or produced by the project and any usage or privacy requirements.


  • Test Data

  • System Output (Data, Interfaces and Reports)


What documentation will be utilized or produced by the project.


  • Contracts or Agreements

  • Cost of Revenue Projections

  • Budgets

  • Requirements

  • Team Member Directories

  • Project Plans

  • Status Reports

  • Change Controls

  • Risk Memos

  • Test Cases and Results

  • Other Intellectual Property

Physical Security

Any physical requirements the project must adhere to.


  • Approved Work Locations

  • Badges and Security

  • Visitors

  • Physical Documentation or Output Storage

  • Take Home Policies

  • Shredding Requirements

Step Two – Plan

Once an understanding of what needs to be secured and why, it is time to develop a plan for project security. This step involves integrating the security needs into the project in terms of required actions, resources, effort and costs. In a larger organization this may require coordination with potentially many different department areas to create a comprehensive plan.

Step Three – Communicate and Implement

After the plan has been developed it is time to implement and communicate to all team members the requirements, rules and processes for security on the project. Often this step takes place in both team member on-boarding and a team kick–off meeting. There also may be some key security actions that are required to take place as the project moves forward by the team or other responsible organizational areas.

It is very important to communicate to all team members what to do if they notice or create a security incident or risk.

Step Four – Monitor and Control

As the project progresses, it is important to check on and monitor the key security risk areas you have identified and compliance processes. This can be accomplished by ensuring actions have been completed, monitoring unusual behavior or checking in on a regular basis with other department areas who have project responsibilities to keep the project secure.

A good way to ensure follow up is to include on a project’s regular status report a project security section that summarizes any incidents and their disposition.

Step Five - Close Out and Transition

After delivery of the required solution, tying up a project correctly from a security perspective is very important. Important steps are securely archiving any project work product or documentation, the off-boarding of team members which may include actions to remove or restrict access to any and all project environments, tools, software or documentation and transitioning the solution and any security processes to a maintenance and support team.

Project Security contains aspects and touch points with many other project management areas including Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management and Project Risk Management. A focused approach to Project Security Management can help deliver a more secure solution, create a more secure project environment, and go a long way towards mitigating many security issues later when they can be more damaging and expensive to fix.


  1. IBM, 2015 Cost of Data Breach Study,

  2. Privacy Rights Clearinghouse, 12/30/2015,

(General Review) National Institute of Standards and Technology (Agency of the U.S. Department of Commerce) Computer Security Division and Computer Security Resources Center, 12/20/2015.

Disclaimer, Copyright and Trademark Statement

This article is provided for informational and educational purposes. It makes no warranties as to the claims, accuracy or fitness of information provided, referenced or cited. Use of the information, instructions and any examples contained in this work is at your own risk. There should be no implied endorsement of this article by any person or organization referenced.

All trademarks, company, product and services names, images, descriptions, or public website content are property of their respective owner as source referenced. It is your responsibility to ensure that your use thereof complies with such licenses and/or rights.


Commenting has been turned off.
bottom of page