IT and Cybersecurity Teams Need to Work Together: A Practical Guide

When uptime and security collide, who decides? Learn how IT and cybersecurity teams can align priorities, assign ownership, and make risk decisions that protect critical business services.

Consider a familiar operational dilemma: security identifies an actively exploited vulnerability in a business-critical system. IT knows the update could disrupt an application with limited rollback options. The business needs the service available. Everyone has a legitimate concern, but nobody has agreed on who makes the decision.

This is where cybersecurity becomes a management problem, not just a technical one. Finding a vulnerability does not fix it. Keeping a system running does not make its risk acceptable.

IT and cybersecurity teams need to work together because dependable business services require both operational reliability and effective protection. The solution is not necessarily a reporting-line change or another meeting. It is a shared operating model: clear ownership, coordinated priorities, tested response procedures, and explicit decisions about risk.

Start With a Shared Business Objective

IT typically emphasizes service delivery, availability, performance, and support. Cybersecurity emphasizes preventing, detecting, and responding to threats. Those priorities overlap, but they can create friction when teams are measured separately.

If IT is rewarded only for uptime, disruptive security updates become difficult to justify. If security is rewarded only for closing findings, operational consequences can receive too little attention.

NIST’s Cybersecurity Framework 2.0 connects cybersecurity governance to organizational objectives and calls for established responsibilities and authorities. It does not prescribe a single organizational chart.

The shared goal is dependable business services with risks the organization understands, assigns, and manages.

Collaboration does not mean eliminating independent challenge. Security should retain an escalation path when operational decisions leave significant exposure unresolved.

Make Responsibilities Explicit—Including Risk Acceptance

For each critical service, distinguish who implements a safeguard, who verifies it, and who can accept the remaining risk. A practical starting model is:

  • IT: Maintains infrastructure and service dependencies; tests and deploys changes; operates backups; restores services.
  • Cybersecurity: Defines protection requirements; evaluates threats and exposure; validates safeguards; leads or supports investigations under the incident plan.
  • Business owners: Identify service criticality, approve business access needs, and establish acceptable disruption and recovery targets.
  • Authorized leadership: Resolves competing priorities, funds necessary work, and approves consequential risk exceptions.

Assign named owners rather than relying on department labels. Include cloud providers, managed service providers, and other partners: a contract does not automatically establish who acts during an emergency.

In smaller organizations, one person may hold several roles. Document those roles anyway, and arrange separate review for significant exceptions where feasible.

Stop treating silence as approval

A deferred security fix should become a documented, time-limited exception—not an aging ticket with no decision. Record the owner, business rationale, exposure, compensating safeguards, authorized approval, expiration date, and review triggers. Risk acceptance should be visible to someone empowered to make that business decision.

Build One Shared View of Critical Services

Both teams need more than a device inventory. They need to understand how technology supports business operations.

Start with one important service and record its business and technical owners, supporting systems, sensitive data, external exposure, identity dependencies, providers, monitoring, and recovery arrangements. Include software-as-a-service applications: someone must own their configuration, access removal, logging, and recovery limitations.

For example, restoring a customer portal may require its identity provider, database, network services, and third-party integrations. A server list alone will not reveal whether the business can complete a customer transaction.

Expand the inventory from a validated service map, rather than waiting for a perfect enterprise-wide catalog.

Turn Vulnerability Reports Into Coordinated Remediation

Security handing IT a scanner report is not a complete remediation process. NIST’s enterprise patch-management guidance treats patching as preventive maintenance and includes identification, prioritization, installation, and verification.

Use the CISA Known Exploited Vulnerabilities catalog as an input to prioritization, alongside asset exposure, business impact, and existing safeguards. A severity score alone does not establish your organization’s urgency.

Create one tracked workflow:

  • Confirm: Identify affected assets and accountable owners.
  • Prioritize: Assess exploitation evidence, reachability, privileges, and service importance.
  • Choose: Patch, apply a validated mitigation, restrict exposure, or retire the system.
  • Execute: Plan testing, deployment, rollback, communication, and escalation.
  • Verify: Confirm the change took effect and retain evidence before closing the work.

Suppose an exposed application cannot be patched without an outage. The joint decision might involve temporarily restricting access while testing an emergency update. Any mitigation must be validated against the actual vulnerability; “behind a firewall” is not automatically sufficient.

The tradeoff is change risk versus exposure risk. Normal maintenance windows should not automatically override urgent threats, but urgency should not erase dependency checks or rollback planning.

Design Access and Monitoring Together

Make stronger authentication supportable

CISA’s #StopRansomware Guide recommends phishing-resistant multifactor authentication. Deploying it requires security requirements, IT compatibility testing, service-desk preparation, and business input.

Test enrollment, lost authenticators, account recovery, and emergency administration. Otherwise, support procedures can become the weak point in an otherwise strong control. Coordinate joiner, mover, and leaver processes so access changes follow business changes promptly.

Collect logs for defined purposes

Joint government logging guidance emphasizes approved policy, centralized access and correlation, secure storage, and threat-relevant detection.

For each important source, agree on required events, collection ownership, alert investigation, access restrictions, retention, and detection of collection failures. Security cannot investigate records that IT assumes someone else is collecting.

More logging is not automatically better. Balance investigation needs against cost, query performance, privacy, and retention obligations. Test whether an analyst can answer a real question—such as which resources a compromised administrator accessed.

Rehearse Incident Decisions and Business Recovery

NIST SP 800-61 Revision 3 integrates incident response into broader cybersecurity risk management. Effective response depends on coordinated responsibilities across technical teams, leadership, and external parties.

Agree on authority before the emergency

Use a compromised-administrator scenario to test who declares an incident, leads coordination, disables accounts, isolates systems, preserves evidence, and approves shutting down a critical service. Include legal, communications, and relevant providers. Establish an alternate communication channel if normal email or collaboration systems are unavailable.

Preauthorize appropriate containment actions within clear boundaries. Fast containment may interrupt operations; delayed containment may expand damage. Those decisions need an escalation path, not improvised negotiations.

Restore a usable service, not just a backup

CISA recommends offline, encrypted backups and regular recovery testing. IT should restore systems and dependencies; security should assess whether the compromise has been addressed; business owners should validate essential transactions.

Agree on recovery-time and acceptable-data-loss targets, then test them. Record elapsed time, missing data, and failed dependencies. A successful backup job does not prove recoverability, and a restarted server does not prove safe restoration.

Measure Shared Outcomes and Start Small

A joint dashboard should make unresolved decisions visible, not reward activity counts. Useful measures include:

  • Ownership coverage: The proportion of critical services with named business and technical owners.
  • Exposure: Applicable known-exploited vulnerabilities still unresolved, including their age and mitigation status.
  • Execution quality: Verified remediations and security changes that cause service disruption.
  • Resilience: Recovery exercises meeting agreed targets and overdue corrective actions.
  • Governance: Expired exceptions and decisions awaiting authorized approval.

Define scope and denominators so trends remain meaningful. Review priorities through a shared work queue that includes operational constraints and required resources.

A suggested 90-day rollout is to establish ownership and map one service first; connect remediation, access, and monitoring workflows next; then run an incident exercise and restoration test. This is an adaptable implementation sequence, not a mandated timeline or a reason to delay urgent fixes.

IT and Cybersecurity Collaboration Checklist

  • Critical services have named business and technical owners.
  • Implementation, verification, escalation, and risk-acceptance authority are documented.
  • Both teams use a shared inventory and prioritized work queue.
  • Remediation includes testing, rollback planning, and verified closure.
  • Exceptions have safeguards, approval, and expiration dates.
  • Authentication changes include support and recovery procedures.
  • Logging has collection, investigation, and retention owners.
  • Incident plans define containment authority and alternate communications.
  • Relevant providers participate in response and recovery planning.
  • Recovery tests include security assessment and business validation.
  • Shared measures track reliability as well as risk reduction.
  • Exercise findings become assigned, tracked corrective work.

Make Collaboration Visible in Completed Work

IT and cybersecurity do not need identical responsibilities. They need connected decisions and accountability for a shared business outcome.

Start this week: select one critical service, bring its IT, security, and business owners together, and identify its most important unresolved risk. Assign the next action, the decision-maker, and the evidence required for closure. That is how collaboration moves from an organizational aspiration to an operating discipline.

Browse all insights · Contact Bart McDonough