Bring IT Into the Decision: Fixing Late Security Reviews and Unclear Approvals

Treat the surprise as a process signal

“This was never mentioned to me at all as the head of IT.” If that is your reaction after a project decision, start by investigating the decision path—not assuming someone deliberately excluded you.

A project may have been labeled a marketing purchase, an operational improvement, or a customer commitment even though it affects data, access, integrations, or contractual security obligations. People may not recognize when IT input is needed.

For founders and CEOs, the goal is not to route every decision through IT. It is to make security-relevant decisions visible early enough for informed choices. For the head of IT, the immediate task is to address the current exposure and then repair the channel that allowed the surprise.

Separate the current risk from the communication failure

Run two workstreams: assess what has already been committed, and understand why you were not involved.

For the current project, establish:

• What was approved, purchased, promised, or deployed?
• What data, systems, access permissions, or customer obligations are involved?
• Is there an immediate exposure, or is the concern a future implementation risk?
• Which commitments are reversible, and who owns the next decision?

If there is a suspected active security incident, use your incident-response process rather than treating it as an ordinary project review. Otherwise, propose a proportionate next step: continue with controls, pause a specific activity, or review before launch.

Avoid declaring the entire project unsafe before understanding it. Equally, do not silently accept risk just because money has already been spent.

Have the conversation without making it territorial

Ask the project sponsor for a short review. Describe the observable gap, explain its consequences, and make a concrete request.

A possible opening is:

I learned about the security-relevant requirements after the project decision. IT did not have an opportunity to assess them before the commitment. That could mean rework or unmanaged risk. Can we map how this decision was made and agree where review needs to happen next time?

Then ask what information existed at each stage, who knew about it, and what the team believed required approval.

This distinguishes missing information from unclear responsibilities, an accidental omission, or a deliberate bypass. Each needs a different response. Focus first on establishing facts, not defending your status.

Define what triggers early IT involvement

“Keep IT informed” is too vague to operate. Agree on a short set of triggers that require consultation before a binding commitment.

Examples include:

• A new vendor processing company or customer data.
• A new integration, external connection, or privileged access arrangement.
• Changes to authentication, hosting, data location, or sensitive-data handling.
• Customer promises concerning security controls, audits, or incident notification.
• Material changes to a previously reviewed project.

Put these questions into the existing purchasing or project-intake workflow. Do not rely on colleagues remembering a separate policy document.

Use a lightweight screening form: project owner, proposed service, data involved, access needed, intended commitment date, and relevant requirements. Allow “unknown” as an answer that prompts clarification rather than guesswork.

Make consultation, approval, and risk acceptance distinct

Being copied on an email is not the same as reviewing a proposal. Reviewing a proposal is not necessarily authority to approve the purchase or accept its residual risk.

Document who does what:

• Project owner: supplies accurate information and requests review early.
• IT or security reviewer: assesses technical and security implications and recommends controls.
• Relevant specialists: review privacy, legal, procurement, or compliance issues when needed.
• Authorized business leader: makes the business decision and accepts permissible residual risk within their authority.

Agree which conditions must be met before contracting, implementation, and launch. Assign these responsibilities to named people, even when one person holds several roles.

The CEO should resolve disputed authority. Risk acceptance must not be used to bypass legal obligations or requirements the organization has no authority to waive.

Build a fast, visible approval path

A process people cannot navigate will invite workarounds. Use one intake location, a named reviewer, and agreed response expectations based on urgency and complexity.

Record the outcome where the project team already works: pending review, approved within a defined scope, approved with conditions, or escalated. Include the decision owner, conditions, and any required reassessment date.

Create an urgent-request route, but require documented decisions and follow-up. When project scope changes, reopen the relevant review rather than assuming the original approval still applies.

Check whether the new channel works

Pilot the process on upcoming projects. Track whether review happened before commitment, how long it took, and where teams encountered confusion. Examine both late referrals and delays caused by the review process itself.

If bypasses continue despite clear rules and accessible support, address them as an accountability issue with the responsible leader. The objective is predictable collaboration—not a larger IT inbox.

If you know you need an important conversation but are unsure how to start, Jessica Hill Holm’s Conversation Compass workbook helps you organize your thoughts, clarify your message, and approach the conversation with confidence. For leaders who want personal support, a coaching call offers space to prepare the discussion and clarify the changes you need.