A featured contribution from Leadership Perspectives, a curated forum for enterprise technology leaders, nominated by our subscribers and vetted by the CIOApplications Editorial Board.

Banner Health

Why do Projects Take so Long (When Information Security is Involved)?

Over the years, I’ve had numerous experiences and swapped stories with colleagues of painful projects that “involved” Information Security. Of course, these weren’t projects lead by Information Security. Instead, at some point, (usually right before the project goes live) someone says, “I think this might need Information Security’s sign-off.” Information Security is then left trying to make an impossible situation work with stakeholders blaming them for delays. At best, this last-minute approach results in significant delays and projects being scrapped. At worst, businesses choose to accept the risk of launching an insecure application or product that will (hopefully) be fixed “later.” Why does this happen, and what can we as leaders do to change this?

In this article, Information Security is a broad term covering the “soft” side: Governance, Risk, and Compliance (GRC), Data Privacy, Legal, etc.—factors that tend to be muddied and grey, and the “hard” side: Antivirus, Firewalls, Patching, etc.—things with a “yes or no” answer as to whether they are in use.

Think back to delayed or failed projects in your organization that involved Information Security. If you were to review the project charter, Gantt chart, stakeholders, and meetings, ask yourself: when and how was Information Security involved and for what percentage of the project? Were they involved in budgeting, scoping, work breakdown structure (WBS), etc.? The problem is perception, beliefs, and organizational behavior.

As leaders, we must look hard at our organization’s perception of information security. I find it generally falls into three broad categories that reflect overall organizational maturity.

1) Avoid: This is heard in messages such as “they slow the project down,” “it takes forever,”“they always make us fix stuff,” and so on. But what if there was a breach and the e-Discovery started? Are there potentially numerous emails, texts, instant messages, etc. pointing to a willful culture of avoiding security? That just isn’t a conversation you want to have with regulators, the press, or the Board.

2) Painful acceptance: The mindset that this must be done.

It’s unpleasant, but it’s good for the project – akin to eating your veggies and taking vitamins. Not ideal, but at least workable.

So what is the solution—have Information Security sit in every meeting and raise their hand if they “see anything”? That didn’t work for Information Technology years ago, and it doesn’t work now for Security. The culture must change. Processes must be put in place to ensure inclusion becomes a transparent part of projects.

Influence or require the following types of change in your organization:

Pre-Project Planning

Complete an initial risk questionnaire (IRQ). Ensure the questionnaire is broad enough to determine cyber risk and trigger information security work areas (hard or soft), leading to informal discussions around level of effort, dependencies, cost, etc. that will be used to SWAG the project.

Project Evaluations

The formal project package should include the IRQ, base cyber risk rating, and input from Security. This will give the business a transparent view into the risk of the project.

Project is Green lighted

Depending on the cyber risk rating, have different levels of involvement from Information Security.

• Low – Consultation and reference to the various policies, procedures, control frameworks, and laws they are responsible for being compliant to.

• Medium – Information security is possibly a stakeholder or at the least, a subject matter expert (SME) involved at strategic touch points and milestones, and mandatory workshops (discussed shortly).

• High – Same as medium, plus information security become stakeholders. Project managers manage risk, with added awareness of security concerns (covered in the workshops). Does this change alter the security posture? Have you run that change by Information Security? Etc.

Workshops

The resources and stakeholders go through workshops tailored to their roles (technical and non-technical). The material covered should include all the relevant company policies, procedures, frameworks, laws, and where to find them. This sets the tone, making resources responsible for baking in “Security” and establishing that information security’s role is to help guide and verify compliance, not do it for them.

In many cases, project resources are vulnerable to risks they thought were someone else’s responsibility. For example: hard coded passwords, use of insecure protocols, using production data in non-production environments, etc. Workshops help close the gaps in security and privacy knowledge and provide resources the added benefit of awareness into controls that auditors validate against, making resources better able to “defend” their choices.

In conclusion, information security, much like legal, privacy, and HR, is enabling the business to traverse muddy waters as quickly as possible while avoiding the rocky shores (breach, fines, sanctions, etc.). By ensuring information security is part of the pre- and ongoing project process, there will be minimal security surprises, thereby avoiding delays, reducing risk, and helping protect the company against liability.

The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.