Higher Education Technology Is a Leadership Problem, Not an IT Problem

Higher education technology leadership connecting governance, risk, compliance and cybersecurity to build stronger institutions.

Technology has become inseparable from the mission of higher education.

It supports enrollment and admissions. Financial aid. Student information systems. Learning management systems. Human resources. Finance. Identity. Communications. Institutional research. Facilities. Campus security. Research. Data analytics. Artificial intelligence. And increasingly, nearly every interaction between an institution and its students, employees, partners, and community.

Yet many institutions still approach technology risk primarily as an IT responsibility.

That model no longer works.

Higher education technology is a leadership issue.

Cybersecurity is a leadership issue.

Technology governance is a leadership issue.

Risk is a leadership issue.

Compliance is a leadership issue.

And whether an institution has the capabilities necessary to accomplish its mission, satisfy its obligations, protect its stakeholders, and move confidently into the future is ultimately a leadership issue.

For Presidents, CIOs, executive teams, and Boards of Trustees, the question is no longer simply:

“Is our technology working?”

The more important question is:

“Does our institution have the technology leadership, governance, controls, cybersecurity, resilience, evidence, and organizational capabilities necessary to support where we need to go next?”

That is a very different conversation.

Higher Education Technology Risk Doesn’t Stop at the IT Department

One of the most important concepts for higher education leaders to understand is that a technology control does not necessarily live inside IT.

Consider something as seemingly straightforward as removing an employee’s access after employment ends.

Human Resources may establish the authoritative employment status.

A supervisor may communicate the departure.

Identity systems may automate portions of the process.

IT may disable accounts.

Application owners may control permissions within individual systems.

Physical-access systems may require separate action.

Privileged accounts may require additional procedures.

Someone must determine whether everything actually occurred.

And the institution should have evidence demonstrating that the control operated as intended.

That is not simply an IT process. It is an institutional control enabled by technology.

The same principle applies throughout higher education.

Data governance involves the departments creating and using information.

Business continuity begins with understanding which institutional processes must continue.

Application access requires business owners to determine who actually needs access.

Third-party risk involves procurement, contracts, data ownership, technology, cybersecurity, and management.

Cybersecurity incidents can quickly become operational, financial, legal, regulatory, reputational, and executive matters.

This is why mature technology governance requires institutions to look beyond organizational silos.

Follow the control, not simply the organizational chart.

What Florida Higher Education IT Audits Can Teach Us

Kraken Technology Solutions has been analyzing a working cohort of 17 Florida public higher-education IT operational audits to better understand recurring control issues across the sector.

Within that coded cohort:

Control DomainAudits With FindingsPercentage of Reviewed Cohort
Account Management14 of 1782.4%
Application Security / Access Review11 of 1764.7%
Authentication11 of 1764.7%
Vulnerability Management11 of 1764.7%
Logging / Monitoring7 of 1741.2%
Configuration Management6 of 1735.3%
Security Awareness4 of 1723.5%

These percentages describe Kraken’s coded working cohort, not every Florida college or university, and they should not be interpreted as saying those institutions “failed.”

They do, however, demonstrate why these controls deserve leadership attention.

The Florida Auditor General itself describes IT internal controls as a critical component of public-entity internal control systems and places responsibility on public-entity management for establishing effective controls. Its IT operational audits examine areas including infrastructure, vulnerability management, data security and integrity, third-party services, and significant systems and processes.  

Recent and historical audits also demonstrate that these reviews are not limited to one technology platform. Florida higher-education audits have examined environments involving systems such as Workday, Oracle PeopleSoft, and Ellucian Banner.  

That matters.

When similar control categories appear across different technology platforms and institutions, leaders should be careful about assuming that purchasing another product will solve the underlying problem.

Sometimes the technology needs improvement.

Sometimes the problem is governance.

Sometimes it is process.

Sometimes ownership is unclear.

Sometimes policy and implementation have drifted apart.

Sometimes a control exists but the institution cannot demonstrate that it operates consistently.

And sometimes several of those conditions exist simultaneously.

Governance, Risk, and Compliance in Higher Education

GRC—Governance, Risk, and Compliance—is sometimes treated as a cybersecurity acronym.

It is much bigger than that.

Governance

Governance answers questions such as:

Who owns this?

Who has authority to make decisions?

Who accepts risk?

Which policies apply?

How are exceptions handled?

How does management know whether controls are working?

What gets reported to executive leadership and the Board?

Risk

Risk connects technical conditions to institutional consequences.

A vulnerability is technical.

The potential interruption of registration, financial aid, payroll, instructional systems, or other critical institutional services is a business and institutional risk.

The two are related, but they are not interchangeable.

Leadership needs to understand both.

Compliance

Higher-education institutions can operate within overlapping regulatory, contractual, audit, privacy, cybersecurity, insurance, and funding-related obligations.

For example, institutions subject to the FTC Safeguards Rule may need to address requirements around written risk assessment, access controls, information inventories, encryption, security monitoring, incident response, service-provider oversight, and reporting to the governing body. The FTC also makes clear that using a service provider does not transfer ultimate organizational responsibility for the information-security program.  

Higher education may also encounter requirements involving FERPA, state law, contractual obligations, cybersecurity insurance, institutional policy, applicable NIST guidance, CIS Controls and Benchmarks, and other requirements depending on the institution and the information or activities involved.

The objective shouldn’t be collecting compliance acronyms.

It should be determining:

What are we required to do, what have we decided to do, what have we actually implemented, and what evidence demonstrates that it works?

Policy Is Not the Same as Control Effectiveness

An institution can have a policy requiring MFA.

That does not establish that MFA is appropriately implemented everywhere it should be.

An institution can have a termination procedure.

That does not prove access is consistently removed from every relevant system.

An institution can require security-awareness training.

That does not demonstrate everyone completed it or that exceptions are being managed.

An institution can have an incident-response plan.

That does not prove the organization can execute it during a real incident.

This distinction is fundamental to mature technology governance.

At Kraken, we think about this as a traceable chain:

Authority / Requirement → Policy → Organizational Responsibility → Standard / Procedure → Administrative & Technical Controls → Technology → Evidence → Monitoring / Exception Management → Management Oversight

Break that chain anywhere and the institution can develop a gap between what leadership believes is happening and what can actually be demonstrated.

That is why evidence matters.

The Board of Trustees Has a Role in Technology Governance

Boards do not need to configure firewalls.

They shouldn’t.

But Boards and governing bodies increasingly need sufficient visibility to exercise appropriate oversight of material technology, cybersecurity, resilience, and compliance risks.

That means leadership needs to be capable of answering questions such as:

  • What are our most significant technology and cybersecurity risks?
  • Which institutional services are most critical?
  • Who owns those risks?
  • Which regulatory and contractual requirements apply?
  • How do we know critical controls are actually operating?
  • Where are we dependent upon individual employees or vendors?
  • What happens if a critical platform becomes unavailable?
  • What material technology investments are approaching?
  • Where are we accumulating technology debt?
  • What is our three-year technology strategy?
  • Are our cybersecurity capabilities appropriate for the institution we are becoming?

In some regulatory contexts, governing-body reporting is explicit. For example, the FTC Safeguards Rule requires the Qualified Individual to report in writing regularly, and at least annually, to the board or equivalent governing body on the information-security program.  

The Board doesn’t need every technical detail.

It needs decision-quality visibility.

Stop Waiting for the Audit to Tell You Where You Stand

Audits are important.

But an audit should not be an institution’s primary mechanism for discovering its technology environment.

A strong leadership team should already be working to understand:

what is working well;

where material risks exist;

where controls require improvement;

where responsibility is unclear;

where institutional knowledge is concentrated;

where technology is approaching end of life;

where vendors create dependencies;

where evidence is insufficient;

where cybersecurity capabilities need to mature;

and what investments will be required over the next several years.

The goal isn’t merely audit readiness.

The goal is institutional readiness.

Audit readiness becomes one consequence of operating a mature institution.

The Institutional Kraken Strategic Technology Assessment

This is where Kraken’s approach differs from a traditional IT assessment.

The Kraken Strategic Technology Assessment (KSTA) is not designed simply to inventory equipment, run a vulnerability scanner, produce a list of technical deficiencies, and recommend products.

And an institutional KSTA is not a financial audit, HR audit, academic audit, or departmental performance audit.

Instead, Kraken evaluates the technology-enabled capabilities and relevant controls that support the institution.

That distinction matters.

We may not be evaluating how HR performs the broader HR function, for example, but an identity-lifecycle control that begins in HR and terminates in Microsoft Entra ID, an ERP, a SaaS platform, or a privileged-access environment may absolutely be relevant.

Again:

Follow the control.

An institutional KSTA can examine areas such as technology strategy and governance, cybersecurity, identity, Microsoft 365, infrastructure, networks, endpoints, applications, ERP dependencies, data governance, vendor management, business continuity and disaster recovery, policy and control alignment, regulatory obligations, AI readiness and governance, technology lifecycle planning, institutional knowledge, and organizational technology maturity.

The purpose is to establish a defensible current state and translate it into an executive roadmap.

Evidence Before Recommendations

Kraken may enter an engagement with hypotheses.

We may have seen similar issues elsewhere.

We may know technologies we trust.

We may have opinions about what a mature environment should look like.

But none of those things should predetermine an assessment finding.

Our principle is straightforward:

We may have a desired destination. We do not manufacture the evidence needed to get there.

If an institution’s existing technology, policy, process, or control satisfies its requirements and operates effectively, it should receive credit for that.

If evidence demonstrates a material gap, we document it.

Recommendations should then follow a traceable path:

Authority / Requirement → Evidence Reviewed → Current State → Gap → Risk → Required Capability → Recommendation

Technology follows requirements.

Requirements should not be invented to justify technology.

That is what an evidence-driven strategic assessment should look like.

What Happens After the Assessment?

This is another place where higher education technology strategy frequently breaks down.

An assessment produces a report.

Everyone agrees with the report.

Then operational reality returns.

Eighteen months later, half the recommendations remain unfinished.

A strategic technology partner should be capable of helping leadership move from:

Assess → Remediate → Govern → Operate → Prove → Improve

That may involve several different capabilities depending upon what the evidence demonstrates.

Co-Managed Cybersecurity

Many colleges already have capable internal IT and cybersecurity professionals.

Good.

The purpose of a strategic partner shouldn’t be to displace them.

It should be to make them more capable.

A co-managed cybersecurity model can combine institutional knowledge and internal personnel with outside security architecture, specialized engineering, SIEM, EDR, threat monitoring, incident-response capability, vulnerability management, 24×7 SOC/MDR coverage, and strategic cybersecurity leadership.

The institution retains ownership of risk.

The internal team retains its organizational context.

The partner expands the available capability.

You hired a cybersecurity analyst. Now give them a cybersecurity organization.

Compliance-as-a-Service and Continuous GRC

Compliance does not end when a policy is approved.

Controls drift.

Employees change.

Vendors change.

Technology changes.

Evidence ages.

Regulations and contractual requirements evolve.

New risks emerge.

A mature GRC capability therefore becomes a lifecycle involving policy management, control ownership, evidence collection, control testing, risk management, exceptions, remediation tracking, third-party risk, management reporting, and audit preparation.

Technology Strategy and Executive Advisory

Institutions also need someone thinking beyond this quarter’s ticket queue.

What should the environment look like three years from now?

Which platforms should be strategic?

Where should the institution standardize?

What should remain internal?

What should be co-managed?

Where does AI fit?

What technology debt exists?

What major capital decisions are approaching?

Where are people or vendor dependencies creating risk?

How should technology investments support institutional priorities?

Those are technology questions.

But they’re also executive questions.

Higher Education Doesn’t Need Another Vendor

Most institutions already have plenty of vendors.

What is often harder to find is a partner capable of seeing across them.

ERP.

Microsoft 365.

Identity.

Network.

Endpoints.

Cybersecurity.

SIEM.

Cloud.

Backup.

Telecommunications.

Applications.

Compliance.

Policies.

Data.

AI.

Internal teams.

External providers.

Executive priorities.

A strategic technology partner should help connect those pieces into an institutional capability rather than simply add another product to the stack.

That is the role Kraken Technology Solutions is building for higher education.

Not replacing institutional leadership.

Not replacing capable internal IT teams.

Not arriving with predetermined product recommendations.

Helping leadership understand the environment, strengthen the institution, expand its capabilities, and execute a deliberate technology strategy.

The Question Higher Education Leaders Should Be Asking

The question isn’t:

“Do we have good IT?”

That’s too small.

The better question is:

“Does our institution have the technology-enabled capabilities necessary to accomplish our mission, manage our risks, satisfy our obligations, protect our stakeholders, and become the institution we’re trying to build?”

If leadership cannot answer that question confidently, finding the answer should be a priority.

Because technology is no longer merely infrastructure supporting the institution.

Technology is part of how the institution operates.

And that makes technology leadership an institutional leadership responsibility.

Understand Where Your Institution Stands

Kraken Technology Solutions works with higher-education leaders to evaluate technology strategy, cybersecurity, governance, risk, compliance, resilience, and institutional technology maturity through the Kraken Strategic Technology Assessment.

The objective is not to manufacture deficiencies or sell predetermined solutions. It is to establish an evidence-driven understanding of the current environment and create a prioritized roadmap for where the institution needs to go next.

If your institution is preparing for growth, modernization, leadership transition, regulatory scrutiny, an upcoming audit, or simply needs a clearer understanding of its technology environment, start with understanding where you stand.

Facebook
Twitter
LinkedIn
Email