DEV Community: Daniel Glover

AI Governance Framework Template

Daniel Glover — Sat, 11 Apr 2026 17:15:23 +0000

Most AI governance discussions go wrong before they begin.

They start with policy language, abstract principles, and oversized committees. What they should start with is a much simpler question: how will we make sure people use AI in ways that are safe, useful, and commercially sensible?

That is the gap most organisations are sitting in right now. Teams are experimenting with copilots, automating workflows, testing internal assistants, and buying AI features bundled into software they already use. Meanwhile, leadership is trying to work out where the risk sits, who owns decisions, and how to stop innovation turning into another unmanaged estate.

A usable AI governance framework solves that. It gives you a repeatable way to approve use cases, set guardrails, assign ownership, and respond when something drifts off course.

NIST's AI Risk Management Framework is useful here because it treats AI risk management as something that should be built into design, development, use, and evaluation. ISO/IEC 42001 pushes in the same direction from a management-systems angle, focusing on structured processes for responsible development and use. The OECD AI Principles reinforce the fundamentals: transparency, accountability, safety, privacy, and human rights. The common thread is clear. Good AI governance is not a one-off policy. It is an operating model.

If you need a practical starting point, this is the template I would use.

What an AI Governance Framework Is Actually For

An AI governance framework is not there to make the organisation sound mature. It is there to help leaders answer five practical questions.

What AI is being used across the business?
Which use cases are acceptable, risky, or prohibited?
Who is accountable for decisions, data, and outcomes?
What checks happen before deployment and during live use?
What happens when an AI system causes harm, confusion, or regulatory exposure?

If your framework cannot answer those five questions quickly, it is too theoretical.

I see a lot of organisations jump straight to the language of responsible AI without sorting out the basics. They publish principles, but they cannot name all the tools in use. They talk about ethics, but they have no intake process. They say a human is in the loop, but nobody can explain when that human intervenes or what authority they actually have.

That is not governance. That is aspiration.

The Seven Parts of a Practical AI Governance Template

A strong framework does not need to be huge. It needs to be clear. I would build it around seven sections.

1. Purpose and scope

Start by defining what the framework covers.

This sounds obvious, but it is where a lot of confusion starts. If you only mean custom-built AI, say that. If you also mean SaaS products with embedded generative AI features, say that too. If the scope includes experimentation, procurement, deployment, and third-party use, make it explicit.

A sensible scope statement might look like this:

This framework applies to any AI-enabled system, feature, service, or workflow used, developed, configured, or procured by the organisation where the output influences decisions, content, operations, customer interactions, or internal business processes.

That gives you room to govern both bespoke tools and off-the-shelf platforms.

2. Principles and decision rules

You do need principles, but keep them short and operational.

Mine would be:

AI must support a clear business purpose.
Human accountability stays with named owners, not the system.
High-impact use cases require stronger review and monitoring.
Personal, confidential, or regulated data must be protected by design.
Users must understand when AI is being used and where its limits sit.
Outputs must be reviewable, challengeable, and, where necessary, reversible.

These principles should map directly to actual decisions. The ICO's AI and data protection guidance is particularly useful on this point. It keeps bringing governance back to accountability, transparency, lawfulness, and fairness rather than letting teams hide behind technical novelty.

3. Use case classification

This is where the framework becomes useful in real life.

Every proposed AI use case should be classified before it goes live. You do not need an elaborate taxonomy. Three tiers are enough for most organisations.

Low risk

Examples: internal drafting support, meeting-note summarisation, code assistance with review, knowledge retrieval for internal teams.

Medium risk

Examples: customer support assistance, workflow automation that affects service delivery, supplier triage, internal decision support, AI-generated content for external publication with human review.

High risk

Examples: decisions affecting employment, access, pricing, compliance outcomes, safety, regulated data handling, fraud judgements, or customer eligibility.

The point is not to label things for the sake of it. The point is to tie classification to controls.

Low-risk use cases might need manager approval and standard logging. High-risk ones may need a DPIA, legal review, security review, testing evidence, named executive ownership, and stricter monitoring.

If you do not classify use cases, everything ends up in the same bucket, and the governance either becomes too weak for serious use or too slow for routine use.

4. Roles and accountability

This section should remove ambiguity.

At minimum, name these roles:

Executive sponsor
Owns overall policy direction, risk appetite, and escalation.

Business owner
Owns the use case, the intended outcome, and the operational impact.

Technical owner
Owns implementation, controls, integration, and monitoring.

Data owner
Owns the legality, quality, and suitability of data used.

Risk or compliance lead
Owns review of regulatory, contractual, and policy implications.

Security lead
Owns security review, access model, supplier assurance, and incident response alignment.

This is also where an AI Centre of Excellence can help. The CoE should not own every AI decision itself, but it can provide standards, templates, review guidance, and shared tooling so business teams do not improvise their own governance from scratch.

5. Approval workflow

If you want the framework to stick, the approval path has to be visible and usable.

A simple approval workflow could be:

Submit AI use case proposal.
Classify risk level.
Complete minimum evidence pack.
Review by business, security, data, and compliance stakeholders as required.
Approve, reject, or approve with conditions.
Register the use case in the AI inventory.
Review performance and risk on a defined cadence.

The evidence pack does not need to be bloated. For most use cases, it should cover:

business purpose
user group
data involved
expected benefits
known risks
human review points
supplier or model details
fallback plan if the tool is withdrawn or fails

That last point gets missed too often. If a vendor changes pricing, access, retention terms, or output quality, what happens to the process that depends on it?

That question links directly to wider procurement discipline. If external suppliers are involved, your AI governance should align with your vendor due diligence process, not sit beside it.

6. Control requirements

This is the core of the template.

I would group controls into six headings.

Data controls
What data is allowed, restricted, or prohibited? Can staff paste customer data into public AI tools? Are prompts retained by the vendor? Is there a private deployment option?

Security controls
How is access managed? Are outputs logged? Is the supplier assessed? What happens if credentials, prompts, or generated content are exposed?

Legal and compliance controls
Does the use case raise GDPR, IP, sector regulation, employment, or contractual issues? Do you need records, notices, or consent changes?

Quality controls
How is accuracy checked? What error rate is acceptable? How are hallucinations, bias, or drift detected?

Human oversight controls
Who reviews the output before action? What decisions must never be fully automated? When can a user override the system?

Operational controls
How is the solution monitored after launch? What triggers re-review? What incidents get escalated?

This is where many organisations discover they do not really have an AI problem. They have a control-design problem. AI just exposes it faster.

7. Monitoring, review, and incident handling

Governance that stops at approval is not governance.

NIST is clear that AI risk management should extend across the lifecycle. That means reviewing systems after deployment, not just before them. In practice, I would expect every live AI use case to have:

a named review cadence
usage and outcome monitoring
issue logging
change control for prompt, model, or workflow updates
incident escalation routes
retirement criteria

This matters because AI systems drift in ways conventional software often does not. The model may change. The vendor may change. Staff may start relying on it in ways the original approval never anticipated. That is exactly how shadow AI becomes a management problem instead of just a tooling trend.

A Simple AI Governance Framework Template

If I were drafting the first working version for an organisation, it would look like this.

AI Governance Framework Template

1. Purpose

Define how the organisation approves, uses, monitors, and reviews AI systems to balance innovation, risk, compliance, and business value.

2. Scope

Applies to all internally built, configured, or procured AI tools and AI-enabled product features used in business operations, employee workflows, customer interactions, analytics, or decision support.

3. Principles

Clear business purpose
Named human accountability
Proportionate controls based on risk
Transparency for users and stakeholders
Protection of personal, confidential, and regulated data
Monitoring and review throughout the lifecycle

4. Risk tiers

Low: internal productivity and drafting support
Medium: operational support and customer-facing assistance with review
High: regulated, high-impact, or decision-shaping use cases

5. Required approvals

Low: business owner plus standard policy compliance
Medium: business owner, security, and data review
High: business owner, security, data, compliance, and executive sign-off

6. Mandatory controls

Approved data handling rules
Supplier and security assessment where relevant
Testing for accuracy and reliability
Human review points for medium and high-risk use cases
Logging, monitoring, and periodic review
Defined fallback or rollback process

7. Documentation requirements

Each use case must record:

owner
purpose
users
tool or model used
data involved
risk tier
approval date
review date
key controls
known limitations

8. Incident handling

Any material AI-related error, harmful output, privacy concern, control failure, or unauthorised use must be logged, reviewed, and escalated under existing security, data protection, or operational incident processes.

9. Review cadence

Low: every 12 months
Medium: every 6 months
High: every 3 months or after material change

That is not the finished state for every organisation, but it is a credible starting point.

Common Mistakes That Break AI Governance

The first mistake is overbuilding. If the framework takes six weeks to approve a low-risk productivity tool, staff will route around it.

The second is underbuilding. If every use case gets waved through because "it is only advisory", you will miss the fact that advisory tools still influence decisions.

The third is separating AI governance from existing governance. AI does not need a magical parallel universe. It needs to connect to security review, procurement, data protection, records management, and incident response.

The fourth is confusing ownership. If no one owns outcomes, the model becomes the scapegoat for human choices.

The fifth is failing to maintain an inventory. You cannot govern what you cannot name.

Where to Start Next Week

If you do not have a framework today, do not wait for the perfect version.

Do these five things first:

Create a simple AI use case register.
Define low, medium, and high-risk categories.
Publish minimum rules for data handling and human review.
Name the owners for approvals, security, compliance, and escalation.
Review the top five live AI use cases already in use.

That will get you further than another month of discussion about principles nobody is applying.

The Bottom Line

A good AI governance framework should make the organisation safer and faster at the same time.

It should reduce uncertainty, not create bureaucracy. It should help teams adopt useful AI with confidence while stopping careless or high-risk use before it spreads. And it should fit the way the business already makes decisions, not float above it as a separate theory of responsibility.

If your current framework is mostly a policy document, simplify it. If you do not have one at all, start with the template above and make it real through ownership, workflow, and review.

That is what governance looks like when it is built for actual operations, not just audit language.

IT Risk Registers Executives Use

Daniel Glover — Fri, 10 Apr 2026 17:05:57 +0000

Most IT risk registers are full of effort and short on value.

They are maintained because somebody sensible once said they should exist. They get reviewed before audits. They are updated after incidents. They sit in governance packs. And yet, when a real decision needs to be made, most executives do not reach for the risk register. They ask for a summary, a briefing, or a fresh view of the issue because the register itself is too technical, too bloated, or too detached from the business.

That is the core problem. A risk register is not meant to be a museum of everything that could go wrong. It is meant to be a decision-making tool.

NIST describes a risk register as a central record of current risks and related information for an organisation. The NCSC makes a similar point from a governance angle. Good cyber risk management should help leaders make better, more informed decisions, and it should be integrated into wider organisational risk management rather than treated as a standalone IT exercise. Those two ideas matter. A useful risk register is current, central, and connected to business decisions.

In practice, that means your register has to work for people outside IT.

I have seen this go wrong more than once. Teams produce a spreadsheet with forty-seven rows, each one scored on a five-by-five grid, and assume the existence of the sheet means the risk is being managed. It is not. If your CFO, COO, or CEO cannot read the register and understand what needs attention, you do not have an executive tool. You have documentation.

Why Most IT Risk Registers Fail

The first failure is that they are written in technical language. The risk statement says something like, "Legacy Windows Server estate approaching end of support may increase vulnerability exposure due to unpatched CVEs." That may be accurate, but it is not executive-ready. The board does not need to decode the phrase "unpatched CVEs". They need to know what is at risk, what the likely business impact is, and what decision is needed.

The second failure is that they confuse activity with control. I often see mitigation fields filled with project names, tooling purchases, or vague phrases such as "security programme underway". That is not useful. An executive needs to know whether the risk is accepted, reduced, transferred, or still sitting there waiting for budget and ownership.

The third failure is volume. Too many registers are dumping grounds. If every local annoyance, minor weakness, and hypothetical edge case appears alongside material operational risk, leaders stop trusting the prioritisation. They should. A register that says everything matters is really saying nothing matters.

The fourth failure is isolation. The NCSC is right to warn against treating cyber risk as a standalone topic. Most meaningful IT risks now have operational, financial, legal, and reputational dimensions. If your risk register sits entirely within IT, disconnected from business planning and enterprise risk, you will miss the real trade-offs.

Start with the Decision, Not the Threat

The easiest way to improve a risk register is to start from a different question.

Do not ask, "What threats do we have?"

Ask, "What decisions might leadership need to make because this risk exists?"

That changes the quality of the entry immediately.

A poor risk entry says:

"Third-party remote access tooling may create security exposure."

A better risk entry says:

"A compromise of third-party remote access into core systems could disrupt order processing and customer service for up to two days. We need a decision on enforcing stronger supplier access controls and funding privileged access tooling this quarter."

The first version names a category. The second version names a business consequence and a decision path.

This is the standard I use: every risk entry should tell an executive five things in plain English.

What could happen.
Why it matters to the business.
How likely it is to happen.
What is currently being done about it.
What decision, investment, or acceptance is required.

If an entry cannot do that, it is not ready for an executive forum.

The Fields That Actually Matter

You do not need a complicated template. In fact, complexity is usually the enemy here. A strong executive-friendly register can work with eight fields.

1. Risk title

Short, specific, readable. For example: "Unsupported production servers" or "Over-reliance on single SaaS vendor".

2. Risk statement

Write this in full-sentence business language. A good structure is: "If [event] happens, then [business impact] may occur, affecting [objective, revenue, service, compliance, or reputation]."

3. Business impact

Keep this concrete. Lost revenue, regulatory exposure, service outage, delayed delivery, failed audit, customer churn, reputational damage. Pick the consequences leadership recognises.

4. Likelihood and impact

Yes, score it if your organisation expects scoring, but do not let the number do all the talking. The NCSC advises using risk metrics with caution because they are easy to misread without context. I agree. A red score without narrative is theatre.

5. Current controls

List the controls that materially reduce the risk now, not everything you wish you had. Be honest. Multi-factor authentication enforced for admins is a control. "Security awareness planned" is not.

6. Gap or exposure

What remains unresolved? This is where the real conversation usually is.

7. Owner

Name one accountable person. Not a team. Not "IT". One person.

8. Next action and due date

If the entry does not point to a next action, it becomes passive. If it does not have a due date, it drifts.

That is enough for most organisations. You can add appetite alignment, financial estimate, or linked controls if your governance model requires it, but the core record should remain readable.

Write the Risk the Way the Business Hears It

This is where most of the improvement comes from.

Compare these two versions.

Weak version:
"Insufficient patching cadence across endpoint estate creates elevated vulnerability exposure."

Better version:
"Laptops used by finance and HR are not consistently patched within the agreed window. If a known vulnerability is exploited, the business could face payroll disruption, data exposure, and reportable compliance impact."

The second version is stronger because it names the business function, the consequence, and the outcome a leader can picture.

The same applies to supplier risk. I covered the front-end procurement angle in my vendor due diligence guide, but governance cannot stop at onboarding. Executive risk management needs to keep asking a harder question: if this supplier fails, is compromised, or underperforms, what happens to us?

That is why strong registers often group risk around business dependency rather than around whichever technology domain owns the issue.

Keep the Register Short Enough to Defend

An executive register should be short enough that you can defend the inclusion of every item.

That does not mean pretending smaller risks do not exist. It means using layers.

I prefer three levels:

Executive register: 5 to 12 material risks that affect strategic objectives, major services, compliance exposure, or meaningful financial outcomes.
Operational register: team-level risks that need management attention but not executive airtime.
Issue log: known defects, control failures, and actions in progress.

Mixing all three together is one of the main reasons registers become unreadable.

NIST's more recent guidance on integrating cybersecurity and enterprise risk management is useful here. The point is not just to record risk locally, but to roll up what matters for broader enterprise oversight. That only works if you separate background operational noise from risks that genuinely deserve leadership attention.

Review Cadence Matters More Than Spreadsheet Design

I have never seen a risk register fail because the template was too simple. I have seen plenty fail because nobody owned the cadence.

The NCSC says changes to risk should be assessed regularly, at least bi-annually, and more often where organisations are exposed to faster-moving threats, business change, or regulated environments. In reality, many IT leaders need a tighter rhythm than that.

A practical operating model looks like this:

Monthly operational review for IT leadership and security stakeholders.
Quarterly executive review tied to strategic priorities, investment decisions, and major change.
Immediate out-of-cycle review after incidents, major supplier changes, acquisitions, restructures, or new regulatory exposure.

That rhythm keeps the register alive. It also prevents the common problem where the risk register says one thing while the business is actively making decisions that assume another.

If you already report IT metrics to the board, this should sit alongside that conversation rather than apart from it. I wrote more about that reporting discipline in IT metrics board reporting. The short version is simple: risk, performance, investment, and strategy should reinforce one another.

What an Executive Wants to See in the Room

When the register is discussed, leaders normally care about three questions.

Has anything materially changed?
New suppliers, acquisitions, delayed projects, failing controls, or shifting threat patterns should be obvious.

Where are we outside appetite?
Executives need to know which risks are being actively tolerated and whether that tolerance is deliberate or accidental.

What decision is needed from us?
Budget, prioritisation, policy support, acceptance, escalation, or intervention.

This is why a one-line summary column can be surprisingly effective. If I were redesigning most registers tomorrow, I would add a field called "Executive takeaway" and force every risk owner to summarise the issue in one sentence. It is a brutal but useful test of clarity.

A Simple Example Structure

If you want a practical format, this is a solid starting point for each row:

Risk: Unsupported warehouse management servers
Statement: If unsupported servers in the warehouse environment are compromised or fail, order fulfilment may be delayed, affecting revenue and customer service.
Impact: High, because the warehouse is time-sensitive and customer-facing.
Likelihood: Medium, due to age, patch limitations, and current exposure.
Current controls: Network segmentation, restricted admin access, monitored backups.
Exposure remaining: No vendor support and limited recovery confidence under peak load.
Owner: Head of Infrastructure.
Next action: Approve replacement budget and migration plan by end of Q2.

An executive can work with that.

The Bottom Line

A good IT risk register does not prove that governance exists. It helps governance happen.

If your register is written for auditors, filled with abstract scores, and disconnected from business decisions, executives will ignore it until something goes wrong. If it is concise, business-readable, and tied to ownership and action, it becomes one of the most useful tools an IT leader has.

That is the standard worth aiming for.

Not a bigger spreadsheet. A better conversation.

Presenting to the Board: An IT Leader's Guide

Daniel Glover — Thu, 09 Apr 2026 17:39:29 +0000

A CFO I worked with some years ago had a rule: every board paper that crossed her desk had to answer one question before it went any further. That question was not "what does this mean technically?" It was "so what?"

It is a deceptively simple test. And it trips up the majority of IT leaders presenting to boards for the first time.

The technical detail is not the problem. IT leaders are, by definition, technically capable people. The problem is that the skills that make someone excellent at engineering, architecture, and technical problem-solving are almost the opposite of the skills required to hold a board's attention and earn their confidence.

This is not a criticism. It is a structural observation. Boards operate at a level of abstraction that is genuinely foreign to technical professionals who have spent their careers thinking in systems, dependencies, and precise specifications. The gap is real, and bridging it is a learnable skill.

Why IT Boards Underperform in the Boardroom

Walk into most board meetings and watch what happens when the IT update arrives. You will typically see one of two patterns.

The first is the technical deep dive. The IT leader presents infrastructure diagrams, upgrade roadmaps, and security architectures. The language is precise and accurate. The board's eyes glaze over. The moment passes. IT is marked as "covered" and the meeting moves on to topics the board feels more equipped to engage with.

The second pattern is the reassurance play. Nothing alarming is raised. Everything sounds like it is under control. The board approves the requested budget item without much discussion. No real engagement happens. And no one in the room has had an honest conversation about what the organisation's technology posture actually means for its future.

Both patterns are failures, just different kinds. The first fails to communicate. The second fails to lead.

The irony is that most boards are acutely aware of their own vulnerability around technology. They know they do not fully understand the technical detail. That awareness makes them simultaneously more dependent on IT leadership for interpretation and more likely to disengage when the material feels inaccessible.

The Three Questions Boards Actually Want Answered

Before you open any presentation software, step back and ask what the board actually needs from this update. In my experience, it boils down to three questions.

Are we at risk? Not "is our firewall configured correctly" or "are we patched against CVE-2026-1234". Boards want to know if there is a material risk to the business that they need to be aware of, and whether management has a grip on it. If the honest answer is yes, they need to know the scale and the plan. If the honest answer is no, they need enough context to trust that assessment.

Are we getting value from our technology investment? Boards approve significant technology expenditure. They want to know whether that spend is producing returns. This does not mean you need a detailed ROI model for every line item. It means you should be able to speak coherently about how technology is enabling the business strategy, and where the gaps are.

Where are we headed? Boards think in three-to-five-year horizons. They want to understand whether the technology strategy is aligned with where the business needs to be, and what the transition looks like. Technology leaders who can speak to direction, not just current state, earn significantly more credibility in the boardroom.

If your board update answers those three questions clearly, you have done your job. Everything else is detail that should serve those answers, not replace them.

Reframing Technical Risk for a Non-Technical Audience

The most common failure mode in IT board communication is translating technical risk into board-appropriate language. This is where most IT leaders either oversimplify to the point of being useless, or stay too technical to be actionable.

The discipline is specificity without jargon. Boards are sophisticated people. They understand risk, probability, financial impact, and consequence. What they do not follow is the operational detail of how a risk materialises or how it is mitigated.

Compare these two framings of the same risk.

Version one: "We are running three Windows Server 2019 instances that will go end-of-support in January 2027. We need to upgrade or migrate these before that date to avoid security vulnerabilities."

Version two: "Three production systems are running software that loses vendor support in nine months. If we do not migrate, those systems will no longer receive security patches, which means any newly discovered vulnerability in that platform becomes an unpatchable exposure on our network. Our current exposure window if this is exploited is approximately GBP 1.2 million based on our incident response costs from the 2024 breach. We have budgeted GBP 85,000 for the migration and the work is scheduled for Q3."

Version two is better not because it is more alarming. It is better because it gives the board what they need: scale, consequence, financial context, and a clear plan. The technical detail is embedded, not foregrounded.

The One-Page Risk Summary

The single most effective board communication tool I have used and recommended repeatedly is a one-page IT risk summary. Not a heat map. Not a traffic light report. An actual one-page summary that fits on a single side of A4.

The format is straightforward. Five to seven items maximum. Each item names the risk, gives a materiality assessment (low, medium, high), describes the current mitigation status, and names the owner. Nothing else.

The power of this format is that it forces prioritisation and it is readable in under two minutes. A board member who has not been in the IT industry should be able to read this document and understand the organisation's technology risk posture without requiring interpretation.

When I implemented this format for a client in the retail sector, the reaction was immediate. The CEO described it as the first IT board paper they had read that actually felt like it was written for them rather than at them. The CFO put it on the risk committee agenda as a standing item. The IT director went from being perceived as a technical operator to being seen as a business partner within two quarters.

What Gets Boards to Pay Attention

Beyond the mechanics of good communication, there are a few behaviours that reliably change how boards engage with IT leadership.

Lead with questions, not answers. Before presenting your strategy or your update, ask the board what they are most concerned about. You might be planning to talk about infrastructure resilience, but if the board is worried about AI adoption, you will lose them before you get to your main point. Brief conversations with the Chair or the CEO before the meeting will tell you what the board's current priorities are. Use that information.

Show trajectory, not just state. A flatline is not a story. If your security posture has improved materially over the past 12 months, show the movement. If your infrastructure reliability has moved from 97% to 99.4%, that trajectory tells a different story to the board than the number alone. Boards respond to direction and momentum.

Be honest about what you do not know. Nothing builds board trust faster than an IT leader who says "I do not know, but I will find out and report back" rather than improvising an answer or deflecting. Boards have seen enough confident nonsense from executives. Genuine intellectual honesty is rare and memorable.

Connect technology to business outcomes consistently. Every significant technology decision should have a business outcome attached to it in your framing. The firewall upgrade is not about security. It is about protecting the supply chain relationships that generate 40% of revenue. The ERP migration is not about software. It is about the operational efficiency that determines whether the company can scale without proportional headcount growth. Make the business case explicit, even when it feels obvious to you.

The Quarterly Rhythm That Works

From a governance perspective, the rhythm of board IT communication matters as much as the content. In my experience, the most effective structure is a quarterly deep-dive combined with a monthly dashboard.

The quarterly session is where strategy lives. This is where you present the IT roadmap, discuss material risks in detail, walk through the performance of major technology investments, and have the longer conversations about direction and capability. This session should be 30 to 45 minutes minimum. If IT is being squeezed into a 10-minute slot in the middle of a packed agenda, you are not doing quarterly governance properly.

The monthly dashboard is a one-page status update. It covers the same risk summary format described above, flags any material changes from the previous month, and notes any decisions required from the board. It should not require the IT leader to be present unless there is a specific agenda item. Boards that receive a monthly IT pulse without requiring a meeting attendance tend to feel more informed and less anxious about technology, which paradoxically tends to result in more engaged and supportive board-level conversations.

The Bottom Line

The ability to present effectively to a board is not a natural skill for most IT professionals. It requires deliberate practice, feedback, and a willingness to be judged on communication outcomes, not just technical ones.

But the business case for developing this skill is straightforward. IT leaders who can hold a board's attention, communicate risk clearly, and connect technology decisions to business outcomes earn more credibility, more budget, and more latitude to do the work that actually needs doing.

The CFO's test is still the right one. Before your next board update, ask yourself: does this answer "so what?" If it does, you are probably ready to present.

Social Engineering: The Human Side of Cybersecurity

Daniel Glover — Wed, 08 Apr 2026 17:44:23 +0000

Your people are your biggest attack surface - and your last line of defence. Here is how to build a security culture that turns users from liability into asset.

Last year, a finance director at a mid-sized retailer received a call from someone claiming to be from the company IT support. The caller knew the director name, their direct dial, and the name of the email provider. Within 12 minutes, the director had handed over credentials that gave attackers access to the accounting platform, the ERP system, and the backup infrastructure. The breach cost GBP 2.3 million and took eight months to fully resolve.

No malware was involved. No zero-day exploit. Just a phone call and carefully researched pretexting.

This is social engineering - and it remains the most effective attack vector in modern cybersecurity, precisely because it exploits the one variable that technical controls cannot fully govern: human behaviour.

Why Technical Controls Are Not Enough

Most organisations have invested heavily in perimeter security, endpoint detection, email filtering, and multi-factor authentication. These controls are necessary, but they operate on the assumption that the person on the other end of the keyboard is the legitimate owner of the credentials. Social engineering breaks this assumption systematically.

A phishing email that bypasses your secure email gateway. A phone call that bypasses your network authentication. A physical tailgate through an unguarded door. These are not technical failures - they are gaps between what your controls assume and what your people actually do.

The 2025 Verizon Data Breach Investigations Report found that 68% of breaches involved a human element, whether through error, privilege misuse, or social engineering. That figure has remained stubbornly consistent across multiple years of the report. This is not a technology problem waiting for a better technological solution. It is a people problem that requires a people solution.

The Anatomy of a Social Engineering Attack

Understanding how social engineers work is the first step to defending against them. Most attacks follow a recognisable pattern.

Reconnaissance. Attackers gather publicly available information about their target. LinkedIn tells them who works in the finance team. Twitter reveals who attended which conference and what they presented. The company website lists leadership names and organisational structure. This phase is entirely passive and entirely legal from the attacker perspective - they are using open source intelligence that anyone with an internet connection can access.

Pretexting. The attacker constructs a believable scenario to initiate contact. This might be a delivery driver with a missing parcel, an IT administrator investigating a suspected breach, or a colleague from another office who has forgotten their access credentials. The pretext does not need to be sophisticated - it needs to be plausible in context.

Exploitation. Once contact is established, the attacker uses psychological levers to escalate access or extract information. Common techniques include authority bias (posing as someone with power), reciprocity (offering something small to trigger a return favour), and scarcity (creating urgency to suppress rational scrutiny).

Disengagement. After achieving the objective, the attacker exits cleanly, often leaving the victim unaware that anything has occurred until much later - if at all.

Building a Security Culture That Stands Up to Pressure

Technical controls alone cannot protect against an attacker who has successfully impersonated a trusted colleague or service provider. The defence has to operate at the human level too.

Make Security Behaviour Visible and Social

One of the most powerful drivers of secure behaviour is the perception that others are doing it too. When security practices are visible - team members questioning unusual requests in meetings, colleagues verifying identity before sharing credentials, managers modelling good hygiene - they become normalised rather than seen as obstruction.

Security champions programmes work on this principle. Select one person per department to act as a security point of contact, give them basic threat awareness training, and empower them to question anything that feels wrong without fear of appearing unhelpful. Over time, security awareness becomes embedded in team culture rather than siloed in an IT department that sends quarterly password reminders nobody reads.

Create Psychological Safety for Verification

The biggest obstacle to effective verification is social friction. Nobody wants to be the person who challenged the finance director when they were just trying to do their job. Nobody wants to call out a colleague they have worked with for years as a potential security risk.

Leaders have to explicitly create permission to verify. This means stating clearly, repeatedly, and from the top of the organisation that questioning unusual requests is expected, not rude. It means celebrating cases where people caught something suspicious rather than treating near-misses as embarrassments to be quietly buried.

A simple script can help: I want to make sure we are doing this securely. Can you verify your identity through the standard channel? This depersonalises the challenge and frames verification as professional diligence rather than personal suspicion.

Measure What Matters

Most security awareness programmes measure completion rates for training modules. Completion rate tells you whether someone clicked through a slide deck, not whether they would make the right decision under pressure. Behavioural metrics are far more valuable.

Track how many people report phishing simulations. Measure the time between a suspicious email landing and it being reported to the security team. Run controlled exercises to see who would hand over credentials under different pretexting scenarios. Use the results to identify where cultural interventions are working and where there are persistent gaps.

The CISO of a global logistics firm I worked with ran quarterly social engineering simulations across all business units and published the results - anonymised but by department - to the executive team. Within 18 months, the钓鱼 reporting rate went from under 5% to over 70%, and the number of credentials actually handed over in tests fell from 23% to under 2%. The published results created accountability in a way that internal reporting to the security team alone never could.

Keep Training Real and Relevant

Generic cybersecurity awareness training that covers password management, phishing, and GDPR compliance does not prepare people for the specific attacks targeting your organisation. The most effective training programmes are built around real incidents - your own or industry equivalents - and focus on the decision points where someone could have stopped the attack chain.

When a social engineering attempt is identified, whether successful or not, treat it as a learning opportunity. Anonymise the details. Walk through what the attacker did, what made it convincing, and what the correct response would have been. This turns every incident into a training moment rather than a post-mortem that only the security team attends.

The Leadership Imperative

Security culture starts with tone at the top, but it cannot stay there. If the CEO cheerfully ignores the IT department advice on a weekly basis, the message that security is optional will filter down through every layer of the organisation. Conversely, if leaders visibly engage with security practices - reporting suspicious emails, completing training without being chased, asking questions when something does not feel right - that culture cascades too.

One of the most effective interventions an IT leader can make is to ensure that the board understands social engineering risk in commercial terms. The retail breach I described at the start of this article was not primarily a technology failure. It was a failure to equip the finance director with the awareness and the permission to question a phone call that should have set off alarm bells.

The return on investment for security culture is difficult to quantify precisely, but the cost of not building it is measurable in breach notifications, regulatory fines, operational disruption, and reputational damage. In a climate where the average cost of a data breach in the UK now exceeds GBP 3 million, the question is not whether to invest in security culture, but how quickly you can build it before an attacker tests whether your people are your weakest link.

Conclusion

Social engineering exploits human psychology rather than software vulnerabilities, which means no technical control can fully eliminate the risk. Your people are simultaneously your biggest attack surface and your most capable last line of defence. Building a security culture that empowers users to question unusual requests, rewards verification over politeness, and treats every incident as a learning opportunity is not a soft initiative - it is a critical security control that compounds in value over time.

The finance director who handed over credentials last year was not incompetent. They were a reasonable professional who had never been taught to treat credential requests with the same scepticism they applied to unsolicited emails. That gap in awareness is fixable. The question is whether your organisation fixes it proactively, or waits until the fix comes in the form of a breach notification.

Docker Compose Self-Hosted Services Guide

Daniel Glover — Mon, 06 Apr 2026 23:24:45 +0000

This article was originally published on danieljamesglover.com.

There is a certain satisfaction in running your own stack. Not because self-hosting is always the right choice, but because the discipline of deploying, securing, and maintaining your own services teaches you things that clicking through cloud consoles never does. You understand what a reverse proxy is doing when you have configured one. You understand secrets management when you have broken something by leaving credentials in a compose file.

I run a self-hosted stack at home and have built similar setups for small IT teams. This guide covers eight services worth running yourself, with working Docker Compose configurations, security notes, and an honest view of where self-hosting earns its keep versus where managed services are the right call.

Before you start, two things. First: Docker Compose is the right tool here. Not Kubernetes, not Nomad, not whatever the current trend is. For a small team or a serious home lab, Compose gives you readable declarative configuration, simple rollback, and low operational overhead. Second: put these services on a segmented network.

The Foundations Before the Services

Every service in this list shares a common infrastructure requirement: a reverse proxy. Running each service on a different host port (:8080, :8443, :3000) is fine for development, but it is a maintenance problem at any scale. You end up with port-mapping spreadsheets, inconsistent TLS handling, and no central place to manage access.

Traefik solves this. It is a container-aware reverse proxy that integrates directly with Docker and manages TLS certificates automatically via Let's Encrypt.

# traefik/docker-compose.yml
services:
  traefik:
    image: traefik:v3.0
    container_name: traefik
    restart: unless-stopped
    command:
      - "--api.insecure=false"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.email=you@example.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt
    networks:
      - proxy

networks:
  proxy:
    external: true

Create the proxy network once with docker network create proxy, then every service joins it and gets a Traefik label for routing.

1. Portainer - Container Management

Portainer gives you a browser-based view of running containers, volumes, networks, and compose stacks.

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - portainer_data:/data
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.portainer.rule=Host(`portainer.yourdomain.com`)"
      - "traefik.http.routers.portainer.entrypoints=websecure"
      - "traefik.http.routers.portainer.tls.certresolver=letsencrypt"
    networks:
      - proxy

Security note: Restrict Portainer to your management VLAN or VPN. The admin account has root-equivalent access to everything Docker can reach.

2. BookStack - Documentation and Knowledge Base

BookStack uses a Book/Chapter/Page hierarchy that maps well to how IT documentation actually works.

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:latest
    container_name: bookstack
    restart: unless-stopped
    environment:
      - APP_URL=https://docs.yourdomain.com
      - DB_HOST=bookstack-db
      - DB_PASS=${DB_PASS}
    volumes:
      - ./config:/config
    networks:
      - proxy
      - internal

  bookstack-db:
    image: mariadb:10.11
    networks:
      - internal

Note the internal: true network for the database - the database container has no external access.

3. Vaultwarden - Password Management

Vaultwarden is a lightweight Bitwarden-compatible server. For a small team sharing infrastructure credentials, it is the right answer.

services:
  vaultwarden:
    image: vaultwarden/server:latest
    environment:
      - DOMAIN=https://vault.yourdomain.com
      - SIGNUPS_ALLOWED=false
      - ADMIN_TOKEN=${ADMIN_TOKEN}
    volumes:
      - ./vw-data:/data

SIGNUPS_ALLOWED=false is essential. After creating the accounts you need, disable open registration entirely.

4. Uptime Kuma - Monitoring

Uptime Kuma monitors URLs, TCP ports, Docker containers, and DNS entries, and sends alerts via Telegram, Slack, email, and a dozen other channels.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    volumes:
      - uptime-kuma:/app/data
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.uptime-kuma.rule=Host(`status.yourdomain.com`)"

5. Gitea - Self-Hosted Git

Gitea is lightweight, fast, and has a GitHub-like interface. The whole thing runs on less than 256MB RAM.

services:
  gitea:
    image: gitea/gitea:latest
    environment:
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=gitea-db:5432
    networks:
      - proxy
      - internal

  gitea-db:
    image: postgres:15
    networks:
      - internal

Security note: Disable public registration after creating your account.

6. Grafana with Prometheus - Metrics and Dashboards

Grafana and Prometheus give you time-series metrics, customisable dashboards, and alerting based on thresholds rather than binary up/down status.

services:
  prometheus:
    image: prom/prometheus:latest
    networks:
      - internal

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASS}
      - GF_USERS_ALLOW_SIGN_UP=false
    networks:
      - proxy
      - internal

Prometheus is on the internal network only. Only Grafana is exposed via Traefik.

7. Nextcloud - File Sync and Collaboration

For a small IT team, the value is control: your files stay on your hardware, you set the retention policy, and you know exactly who has access to what.

8. Homepage - Service Dashboard

When you are running eight services, you want a single place to see them all. Homepage is a customisable application dashboard that integrates with Docker to pull running container status automatically.

The Security Baseline That Actually Matters

Secrets stay out of compose files. Use a .env file. Add .env to .gitignore immediately.
Separate networks by trust level. Public-facing services on the proxy network. Database containers on internal-only networks.
Run scheduled security scanning. Trivy and Docker Bench for Security are worth running regularly.
Back up volumes, not just images. The image is replaceable. Your BookStack content and Vaultwarden data are not.
Pin image versions in production. latest can introduce breaking changes on pull.

Read the full guide with complete compose configurations at danieljamesglover.com

IT Budget Business Case Template

Daniel Glover — Sun, 05 Apr 2026 17:14:27 +0000

This post was originally published on danieljamesglover.com.

Most IT budgets get rejected not because the investment is wrong, but because the case is made in the wrong language. I have presented infrastructure spending to boards at organisations with turnover north of GBP 110 million. The proposals that got approved were not the most technically sophisticated. They were the ones that translated risk, cost, and opportunity into terms a finance director and non-technical board members could evaluate.

This post sets out the framework I use: a practical IT budget template and a step-by-step approach to building a business case that survives scrutiny from finance, operations, and executive leadership. Whether you are seeking approval for a network refresh, a new security platform, or a cloud migration, the structure is the same.

Why Most IT Business Cases Fail

The most common failure mode is leading with technology. The business case starts with a description of the proposed solution, moves into technical specifications, and ends with a cost figure. The board or CFO says no, or asks for it to be revisited next quarter, and the IT leader cannot understand why.

The problem is framing. The board is not evaluating a technology purchase. They are evaluating a risk and return decision. If your business case reads like a procurement document rather than an investment proposal, it will be treated accordingly.

The second failure mode is undercosting. IT leaders frequently present the capital cost of new infrastructure while omitting ongoing operational expenditure, integration costs, staff training, and decommissioning of legacy systems. When the finance team finds the gaps, it damages credibility and kills the proposal. Present the full picture up front.

The third failure mode is ignoring the do-nothing option. Every business case should model what happens if the investment is not made. Sometimes the cost of inaction is obvious. Often it needs to be made explicit: what does continued reliance on legacy infrastructure cost in downtime risk, security exposure, and staff productivity?

The IT Budget Template Structure

A well-structured IT business case has eight components. Each one answers a specific question the board will ask.

1. Executive Summary

One page maximum. State the problem, the proposed solution, the total cost, and the recommended decision. Write this last, but put it first. The board should understand your ask before reading a single word of detail.

The executive summary should answer three questions: What are we solving? What are we proposing? What will it cost and what do we get in return?

2. Problem Statement and Context

Describe the current state in business terms. Not "our SAN is end-of-life" but "our primary storage infrastructure has exceeded its supported lifespan, creating unplanned downtime risk and limiting our ability to support growth targets." Anchor the problem in business impact: revenue risk, regulatory exposure, operational inefficiency, or competitive disadvantage.

Include context that makes the scale legible. If the organisation is planning to grow headcount by 40% over two years, the infrastructure must support that growth. If a regulatory deadline is approaching, quantify the fine exposure. If the current system goes down, what does an hour of downtime cost?

3. Options Appraisal

Never present a single solution. Boards instinctively distrust proposals that arrive with only one option, because it suggests the decision has already been made and approval is being sought retrospectively.

Present at least three options:

Option A: Do nothing. Model the risk and cost of maintaining the status quo. Deferred investment is not free. Legacy systems accumulate technical debt, require increasing maintenance spend, and create exposure that grows over time. Force the board to weigh inaction explicitly rather than treating it as the default safe choice.

Option B: Minimum viable investment. The smallest intervention that meaningfully reduces risk. This is not the preferred option, but it gives the board a lower-commitment path and frames the recommended option against a meaningful baseline.

Option C: Recommended solution. The full proposal. Justify why this is the right balance of cost, risk reduction, and strategic value.

If there is a fourth option worth considering (for example, outsourcing versus insourcing, or a phased approach versus a full replacement), include it. The point is to demonstrate rigour, not to limit choices artificially.

4. Financial Analysis

This is the section most IT leaders underinvest in, and it is the one that matters most to finance. The financial analysis must cover four areas:

Total cost of ownership (TCO). Hardware or licensing, implementation and integration, staff time and training, ongoing support and maintenance, and decommissioning costs. Be comprehensive. If you are moving to a subscription model, show the multi-year cost trajectory. If the capex converts to opex, model both and explain the cash flow implications.

Cost of inaction. Quantify the risk exposure of not investing. For infrastructure, this typically means: what does a failure event cost? Estimate the probability of that event over a two to three year window and multiply through. A storage system with a 15% chance of failure per year, combined with an estimated GBP 50,000 cost per day of unplanned downtime, represents a meaningful expected loss that belongs in the financial model.

Return on investment (ROI). Where the investment generates measurable returns, quantify them. Staff productivity gains, licence cost savings from consolidation, reduction in vendor support costs, and efficiency improvements from automation are all quantifiable. Use conservative estimates and show your workings. Finance teams apply significant scepticism to benefit projections, so a credible conservative case will outperform an optimistic one that gets challenged.

Payback period. How long until the investment pays for itself? For infrastructure with a primarily risk-reduction rationale, this question is harder to answer, but you can frame it in terms of avoided cost. If the investment costs GBP 80,000 and prevents an event that would cost GBP 200,000, the payback period is essentially immediate on an expected-value basis.

5. Risk Assessment

Map the risks of the proposed investment against the risks of not investing. Use a simple impact-likelihood matrix. The board should see clearly that the risks of the investment (implementation disruption, cost overrun, technology lock-in) are bounded and manageable, while the risks of inaction are open-ended and growing.

Include dependencies and assumptions. If the proposal relies on a third-party vendor delivering on time, flag that. If it assumes a level of internal resource that may not be available, be explicit. Boards appreciate transparency about uncertainty. What they do not appreciate is discovering unacknowledged risks after approval.

6. Implementation Plan

A high-level timeline showing key phases, milestones, and decision points. This does not need to be a full project plan, but the board needs confidence that the IT function has thought through delivery, not just procurement.

Include resourcing. Will this be delivered with existing staff, or does it require contractor support? If procurement is required, what is the expected timeline? Are there dependencies on third parties that could affect the schedule?

7. Success Metrics

How will you measure whether the investment delivered what it promised? Define the metrics before you seek approval, not after. For infrastructure, typical measures include: system availability (target versus baseline), incident frequency, performance benchmarks, and staff productivity indicators.

Having pre-agreed success metrics serves two purposes. It forces rigour in the proposal itself, because vague benefits produce vague metrics. And it gives the board a mechanism to hold IT accountable without micromanaging delivery.

8. Recommendation

Restate the recommended option and the ask. Be direct: "I am recommending Option C at a total cost of GBP X, to be funded from [capital budget / operational budget / a combination]. I am requesting approval to proceed at today's meeting."

Do not make the board infer your recommendation from the preceding analysis. State it explicitly and make it easy to approve.

Presenting to Finance First

Before the board meeting, present the business case to your CFO or finance director. This is not optional. It serves three functions.

First, it gives finance the opportunity to pressure-test the numbers before the board sees them. If there are gaps or errors, you would rather find them in a conversation with the CFO than in front of the full board.

Second, it builds a coalition. A CFO who has reviewed and supports the proposal is an ally in the board meeting. If questions arise about the financial modelling, having the CFO validate your approach is significantly more powerful than defending it alone.

Third, it demonstrates the maturity of the IT function. An IT leader who turns up to the CFO's office with a properly structured financial model, rather than a deck of technical diagrams, signals that technology is being run as a business function.

Handling Pushback

The most common objections to IT budget proposals, and how to respond to them.

"Can we delay this to next quarter?"

Quantify the cost of delay. If waiting three months means continuing to operate vulnerable infrastructure, what is the expected cost of a security incident in that window? If a project is time-sensitive due to a contractual commitment or a regulatory deadline, be specific. Delay is a decision, not a neutral outcome.

"Is there a cheaper option?"

You anticipated this by presenting the options appraisal. Walk back to Option B and explain why it is insufficient: what risks it leaves unresolved, what future costs it defers, what capability gaps remain. The goal is not to dismiss the question but to demonstrate that cheaper options have already been evaluated and found wanting.

"What is the ROI?"

For investment with a primarily risk-reduction rationale, the language of ROI can be misleading. Reframe it: the investment does not generate a return in the traditional sense, but it avoids a cost. You do not typically calculate the ROI of building fire escapes. The question is whether the avoided risk justifies the spend.

For investments with genuine productivity or revenue implications, have the numbers ready. Be conservative and show your workings.

"What if it goes over budget?"

Acknowledge the risk and explain your mitigation. Fixed-price contracts where appropriate, contingency reserves built into the proposal, phase-gating that preserves the option to pause if costs escalate. Boards are not expecting certainty; they are expecting prudence.

The One-Page Version

For smaller investments or organisations with a lighter governance process, the full eight-section template may be more than is needed. In those cases, a single page covering the following is sufficient:

What is broken or at risk right now
What we are proposing and why this option
Total cost (capex and opex, multi-year where relevant)
What happens if we do not do this
What success looks like and when we expect to see it
Decision requested

The principle is the same regardless of format: ground the proposal in business impact, show the full cost picture, and make the decision easy to say yes to.

Connecting Budget to Strategy

The strongest IT budget proposals are not standalone funding requests. They are explicitly connected to the organisation's strategic objectives.

If the business is growing through acquisition, infrastructure investment that supports integration capacity is not overhead: it is an enabler of the growth strategy. If the organisation has a compliance obligation, security investment is not discretionary: it is a requirement. If the business is automating operational processes to reduce headcount costs, the technology enabling that automation has a direct and calculable return.

This connection only works if IT has visibility into business strategy, which means IT leadership needs to be present in strategic planning conversations, not just budget-setting ones. The IT function that waits to be told what to spend cannot make a compelling case for investment. The IT function that understands where the business is going can position every infrastructure proposal as an enabler of the journey.

This is, ultimately, the difference between IT as a cost centre and IT as a strategic function. The budget template is a tool. The mindset shift is the work.

Practical Starting Points

For IT leaders building their first structured business case, I recommend starting with your highest-risk legacy system and working through the cost-of-inaction model. The numbers are usually more compelling than expected, because risk exposure is almost always underestimated when it is not explicitly quantified.

If you have not already built a relationship with your CFO or finance director as a peer rather than a budget supplicant, start there before the next investment cycle. The business case conversation is much easier when finance already trusts your judgement.

And if you are presenting to a board that has historically treated IT as overhead, the metrics and board communication approaches covered in IT metrics that matter to boards are worth reviewing alongside this framework. Structural changes in how IT is perceived take multiple cycles, but they start with the quality of the case you put in front of the room.

The full IT strategy review checklist is also a useful companion for aligning your budget cycle with broader strategic planning, particularly if you are setting priorities across a mixed portfolio of maintenance, growth, and transformation investment.

Daniel Glover is an IT Director and technical consultant with experience leading infrastructure and security programmes at mid-market and enterprise scale. He works with IT leaders on strategy, governance, and the organisational dimensions of technology delivery.

Proxmox Backup and Disaster Recovery Guide

Daniel Glover — Thu, 02 Apr 2026 17:05:29 +0000

Most backup strategies look fine in a diagram. There is production, there is backup storage, there is some kind of retention policy, and there is a comforting sentence about disaster recovery. Then a host fails, a datastore corrupts, or ransomware lands on the management network, and you discover the truth: you did not have a recovery strategy, you had a hope strategy.

I like Proxmox because it makes the mechanics of backup straightforward. The dangerous bit is that this can create false confidence. Clicking "Add backup job" is easy. Building a recovery setup that survives hardware failure, operator error and a bad week is not. This guide is the practical version of what I look for when setting up Proxmox backups for a small IT team or a serious home lab.

If you need the leadership view first, read my guide to an IT disaster recovery plan that actually works. If you are thinking specifically about active attack scenarios, pair this with the ransomware response playbook. This post is about the hands-on Proxmox layer underneath both.

What Good Looks Like

A usable Proxmox backup and DR setup does five things well:

It backs up every important VM and container automatically.
It keeps enough restore points to be useful without filling storage.
It isolates backup storage from the main virtualisation environment.
It proves recoverability with regular test restores.
It gives you an off-site option so one hardware problem does not take out everything.

That sounds obvious, but most weak setups fail on one of those five points. The most common mistake is treating backup completion as the goal. It is not. Recovery within an acceptable time is the goal.

Start With the Failure Modes

Before touching the GUI, define what you are defending against.

For most Proxmox environments, the realistic failure modes are:

Single VM or container issue. Bad update, accidental deletion, filesystem corruption.
Host failure. Disk dies, motherboard dies, bad kernel update, RAID issue.
Storage failure. Local datastore corruption or accidental removal.
Security incident. Compromised admin account, malicious encryption, attacker targeting backup infrastructure.
Site loss. Fire, theft, power event, or catastrophic network issue.

Your design should map to those scenarios. Local backups help with VM mistakes. Separate backup infrastructure helps with host failure. Off-site replication helps with site loss. If one control is supposed to solve everything, it probably solves less than you think.

Proxmox Backup Server Beats Dumping Files to NFS

Proxmox VE can back up to file-level storage, and that is still better than having nothing. But if you are taking this seriously, use Proxmox Backup Server.

The reason is not fashion. It is capability.

Proxmox Backup Server gives you de-duplicated storage, better retention handling, verification workflows, and sync jobs to a remote PBS instance. Proxmox also explicitly recommends PBS on a dedicated host because of those advanced features. For a small team, that translates into two practical benefits: lower storage growth and a cleaner path to off-site copies.

If you are still writing backup archives to the same host cluster, ask yourself a brutal question: what happens if the host storage, the hypervisor, and the backup target all fail together? If the answer is "that would be awkward", you do not have enough separation.

My Baseline Architecture

For a small but sensible setup, I would aim for this baseline:

Primary Proxmox VE host or cluster running production workloads.
Dedicated Proxmox Backup Server on separate storage, ideally not on the same disks as the workloads.
Nightly backup jobs for all critical VMs and containers.
Prune schedule that keeps short-term and long-term restore points.
Verification jobs to detect corruption before you need a restore.
Off-site copy using a second PBS instance or another synced destination.

If you can only afford one improvement this month, make it the dedicated PBS host. If you can afford two, add off-site sync.

Backup Mode Choices Matter

Proxmox gives you different backup modes, and they are not interchangeable.

For VMs, snapshot mode is usually the right default because it keeps downtime low. With the guest agent enabled, Proxmox can freeze and thaw the filesystem to improve consistency. Stop mode gives you the highest consistency, but at the cost of downtime, so I reserve it for workloads where application-level consistency matters more than availability.

For containers, the decision depends more on storage and tolerance for interruption. Snapshot mode is excellent when the underlying storage supports it. Suspend mode can reduce downtime, but it needs temporary space. Stop mode is the blunt instrument. Use it when simplicity matters more than elegance.

The mistake here is picking one mode for everything without thinking about workload behaviour. Domain controllers, databases, app servers and throwaway lab machines do not all deserve identical handling.

Retention: Keep More Than Yesterday, Less Than Forever

Retention is where people either hoard uselessly or prune themselves into danger.

A practical retention policy for a small team might look like this:

Keep 7 daily backups
Keep 4 weekly backups
Keep 3 monthly backups
Keep 1-2 yearly backups for critical systems

That gives you recent rollback points, medium-term safety for slow-burn issues, and a minimal historical archive. The exact numbers depend on data churn and storage budget, but the principle is stable: retain enough history to catch corruption, mistakes and delayed detection.

Remember that ransomware and insider mistakes are not always discovered on the same day they happen. If your retention only covers the last three days, you may be faithfully preserving three versions of a bad outcome.

Backup Isolation Is Non-Negotiable

I have written before that attackers increasingly target backup systems because destroying recovery options dramatically increases the chance of payment. The same logic applies in Proxmox environments.

A few practical rules:

Put backup infrastructure on a restricted management network.
Do not use the same credentials everywhere.
Limit who can reach PBS over the network.
Do not mount the backup datastore casually on random admin machines.
Treat the backup server as a critical security asset, not a storage afterthought.

If your Proxmox host, your PBS server and your admin workstation all sit on the same flat network with shared credentials, you have convenience, not resilience. The home lab segmentation guide applies here too. Good backup design and good network design are joined at the hip.

Off-Site Copies Are Where DR Becomes Real

Local backup is backup. Off-site backup is disaster recovery.

This is where PBS sync jobs are so useful. A remote PBS can pull datastore contents into a local target on a schedule, which gives you a workable off-site pattern without building a completely separate toolchain. For small teams, that is attractive because it keeps operations consistent. Same interface, same restore logic, less context switching.

The point is not just geography. It is blast radius.

If the primary site is lost, encrypted or electrically unwell, you need a copy that was not affected by the same event. That might be a second office, a co-lo box, or a trusted remote location over a tunnel. However you do it, make sure the off-site path is tested and not just documented.

Verification and Restore Testing

This is the part that separates adults from optimists.

A backup job finishing successfully does not prove the backup is restorable. It proves a process completed. You still need to validate the result.

My rule is simple:

Verify backups routinely so corruption surfaces early.
Test restores monthly for at least one representative workload.
Time the restore so you know whether your recovery objectives are fantasy.
Document the gotchas you hit during restore, not just the happy path.

A sensible restore test matrix includes:

One small utility VM
One business-critical application VM
One container
One file-level restore from inside a backup

If you have never restored a Proxmox VM under pressure, do not assume you know how long it takes. You will discover little frictions you forgot to model: VLAN mappings, IP conflicts, DNS updates, missing credentials, application service dependencies. This is exactly why testing exists.

A Simple Recovery Runbook Template

Every Proxmox environment should have a short recovery runbook. Not a sixty-page binder. A short document somebody can use at 3 AM.

Mine would include:

Where backups live
Which credentials are needed and where they are stored
The order in which core systems should be restored
Network dependencies for each critical VM
Approximate restore times from the last successful test
Who signs off on failover or rebuild decisions

This is where technical recovery joins business reality. Restoring the wrong system first can waste hours. Your monitoring, identity and DNS services often matter more than the application people shout about first.

Common Proxmox Backup Mistakes

I see the same issues repeatedly:

Backing up to the same failure domain. If your VM storage and backup storage rely on the same physical box, you have reduced recovery options.

No guest agent on important VMs. Snapshot backups are better with proper filesystem quiescing.

No retention logic. Backups either accumulate until storage fills or get pruned too aggressively.

No verification. Corruption remains invisible until the worst possible moment.

No restore drills. The team learns the process during an incident instead of before one.

No off-site copy. One bad event can wipe out both production and recovery.

These are all fixable. None of them are glamorous. They are also the difference between a manageable incident and a career-limiting week.

Where I Would Start This Week

If your current Proxmox backup setup is basic, do these in order:

Stand up a dedicated Proxmox Backup Server.
Move critical VM and container backups onto a nightly schedule.
Apply a sensible retention policy.
Restrict network access to PBS.
Run one restore test and record the actual time.
Add a remote PBS sync for off-site protection.

That sequence gets you from "we do backups" to "we have the start of a disaster recovery capability".

The main thing to remember is that Proxmox makes backup accessible, but accessibility is not the same as resilience. Resilience comes from separation, verification, testing and repetition. If you build those habits into your environment now, the next incident is still unpleasant, but it stops being existential.

And that is the real goal. Not perfect diagrams. Not backup dashboards full of green ticks. Just the quiet confidence that when something breaks, you know exactly how you are getting it back.

Automated Security Scanning for Small IT Teams

Daniel Glover — Wed, 01 Apr 2026 17:04:33 +0000

Most vulnerability scanning advice assumes you have a dedicated security team, a six-figure tooling budget and a CISO who signs off on quarterly pen tests. If you are running IT for a small or mid-sized organisation with one to five people on your team, that advice is useless.

You still need to find vulnerabilities before attackers do. You just need to do it with free tools, limited time and no dedicated security analyst. The good news is that the open source ecosystem has matured to the point where a small team can build an automated scanning pipeline that runs daily, catches real issues and costs nothing beyond the server it runs on.

I have built exactly this kind of pipeline across several organisations. This guide covers the tools I actually use, how to stitch them together, and how to avoid drowning in false positives when you do not have the headcount to triage thousands of findings.

The Problem with Enterprise Scanning Tools

Enterprise vulnerability scanners like Qualys, Rapid7 InsightVM and Tenable Nessus Professional are excellent products. They are also designed for organisations with security operations centres, dedicated vulnerability management teams and annual budgets north of fifty thousand pounds.

When you license one of these for a small team, three things tend to happen:

The scan runs, produces 4,000 findings, and nobody has time to look at them. A vulnerability scanner that generates noise you cannot act on is worse than no scanner at all. It creates a false sense of security.
The tool sits idle after the initial excitement wears off. Without a dedicated person to maintain scan schedules, update plugins and chase remediation, the scanner becomes shelfware.
You spend your entire security budget on detection and have nothing left for remediation. Finding vulnerabilities is only half the job. Fixing them is where the real work happens.

Small teams need a different approach. Fewer findings, higher confidence, automated scheduling and zero licensing cost.

The Scanning Stack I Recommend

After testing dozens of tools over the years, I have settled on a stack of four open source scanners that cover different layers of the infrastructure. None of them cost anything. All of them can be automated with cron jobs or CI pipelines.

1. Nuclei - Network and Web Application Scanning

Nuclei from ProjectDiscovery has become my default scanner for anything HTTP-facing. It uses YAML-based templates to check for specific vulnerabilities, misconfigurations and exposed services. The community template library covers over 8,000 checks and grows daily.

What makes Nuclei exceptional for small teams is its signal-to-noise ratio. Each template targets a specific, known issue. You do not get vague "possible vulnerability" findings - you get "this exact CVE is present on this endpoint" or nothing. That precision means you can actually act on every finding.

A basic scan looks like this:

nuclei -u https://yoursite.com -t cves/ -t misconfigurations/ -severity critical,high -o results.txt

Filter by severity from day one. Critical and high findings only. You can expand to medium later once you have a handle on the serious stuff.

2. Trivy - Container and Infrastructure Scanning

If you run Docker containers (and most organisations do at this point), Trivy from Aqua Security is essential. It scans container images, filesystem paths, Git repositories and Kubernetes clusters for known CVEs in OS packages and application dependencies.

trivy image your-app:latest --severity CRITICAL,HIGH
trivy fs /path/to/project --severity CRITICAL,HIGH

Trivy also scans Infrastructure as Code files (Terraform, CloudFormation, Dockerfiles) for misconfigurations. One tool covers both your running containers and your deployment templates.

3. OpenVAS - Traditional Network Vulnerability Scanning

OpenVAS (now part of Greenbone Community Edition) is the open source equivalent of Nessus. It runs authenticated and unauthenticated scans against network hosts, checking for missing patches, weak configurations and known vulnerabilities across operating systems, network devices and services.

OpenVAS has a steeper learning curve than Nuclei or Trivy. The initial setup involves deploying the Greenbone Community containers, syncing the vulnerability feed (which takes hours on first run) and configuring scan targets. But once it is running, it provides the deep network-level scanning that web-focused tools miss.

I deploy OpenVAS on a dedicated VM and schedule weekly full scans overnight. The web interface generates PDF reports that you can hand directly to management or auditors.

4. CIS Benchmarks with Lynis - Host Hardening Audits

Vulnerability scanners find known CVEs. They do not tell you whether your Linux servers are actually hardened. Lynis fills that gap by auditing system configurations against CIS benchmarks and security best practices.

lynis audit system --quick

Lynis checks SSH configuration, firewall rules, file permissions, kernel parameters, authentication settings and dozens of other hardening controls. The output is a prioritised list of suggestions with a hardening index score. Run it monthly against your server fleet and track the score over time.

Building the Automation Pipeline

Individual tools are useful. An automated pipeline that runs them on a schedule and delivers actionable results is transformative. Here is how I structure it.

The Architecture

Everything runs from a single management VM or server. In my current setup, that is a Debian VM on Proxmox with 4GB of RAM and 2 CPU cores - nothing expensive. The pipeline is orchestrated by simple bash scripts triggered by cron.

Management VM
├── Nuclei (daily, web targets)
├── Trivy (daily, container images)
├── OpenVAS (weekly, network hosts)
├── Lynis (monthly, server audit)
└── Report aggregator (sends summary)

Step 1: Define Your Targets

Before you scan anything, build a target inventory. You cannot secure what you do not know about. I use NetBox for this, but a simple spreadsheet works if you are starting out. What matters is having a definitive list of:

All public-facing domains and subdomains
All internal IP ranges and subnets
All container images you deploy
All servers and network devices

If you have already segmented your network, you will have a natural structure for organising scan targets by zone.

Step 2: Create the Scan Scripts

I keep each scanner in its own script so they can run independently or together. Here is a simplified version of the daily web scan:

#!/bin/bash
# daily-web-scan.sh
DATE=$(date +%Y-%m-%d)
TARGETS="/opt/scanning/targets/web-targets.txt"
OUTPUT="/opt/scanning/results/${DATE}-nuclei.json"

nuclei -l "$TARGETS" \
  -t cves/ -t misconfigurations/ -t exposures/ \
  -severity critical,high \
  -json-export "$OUTPUT" \
  -silent

# Count findings
CRITICAL=$(grep -c '"severity":"critical"' "$OUTPUT" 2>/dev/null || echo 0)
HIGH=$(grep -c '"severity":"high"' "$OUTPUT" 2>/dev/null || echo 0)

if [ "$CRITICAL" -gt 0 ] || [ "$HIGH" -gt 0 ]; then
  echo "ALERT: ${CRITICAL} critical, ${HIGH} high findings" | \
    mail -s "Security Scan Alert - ${DATE}" security@yourcompany.com
fi

The container scan follows the same pattern:

#!/bin/bash
# daily-container-scan.sh
DATE=$(date +%Y-%m-%d)
IMAGES=$(docker image ls --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>')

for IMAGE in $IMAGES; do
  trivy image "$IMAGE" --severity CRITICAL,HIGH --format json \
    >> "/opt/scanning/results/${DATE}-trivy.json"
done

Step 3: Schedule with Cron

# Daily scans at 02:00
0 2 * * * /opt/scanning/daily-web-scan.sh
0 3 * * * /opt/scanning/daily-container-scan.sh

# Weekly network scan on Sunday at 01:00
0 1 * * 0 /opt/scanning/weekly-network-scan.sh

# Monthly hardening audit on 1st at 04:00
0 4 1 * * /opt/scanning/monthly-lynis-audit.sh

Run scans outside business hours. Network scans in particular can generate noticeable traffic, and you do not want to interfere with production systems during the working day.

Step 4: Aggregate and Report

The biggest mistake small teams make is generating scan reports that nobody reads. My approach is brutal simplicity: one daily email with three numbers.

Critical findings: drop everything and fix these today
High findings: plan remediation this week
Delta from yesterday: are things getting better or worse?

If all three numbers are zero, the email is one line: "No critical or high findings. All clear." That takes two seconds to read and confirms your systems are in good shape.

For management reporting, I generate a monthly summary showing the trend over time. A chart that shows critical findings decreasing week over week is the most powerful evidence you can present to justify your security programme.

Handling the Results Without Drowning

A scanning pipeline that generates findings is only valuable if you can act on them. With a team of one to five people who also handle helpdesk tickets, infrastructure projects and everything else, you need a triage system that is ruthless about prioritisation.

The Three-Bucket Approach

Bucket 1: Fix immediately (critical severity, internet-facing). These are the findings that could lead to a breach tomorrow. Known exploited vulnerabilities on public-facing systems. Exposed admin panels. Default credentials. Drop whatever you are doing and patch.

Bucket 2: Fix this sprint (high severity, or critical on internal systems). These are serious but not imminently exploitable. Missing patches on internal servers, weak TLS configurations, outdated container base images. Schedule them into your normal work cycle.

Bucket 3: Accept or suppress (medium/low, or known exceptions). Some findings are informational. Some are false positives for your environment. Some are on systems you are decommissioning next month. Mark these as accepted with a reason and move on. Do not let them clutter your dashboard.

Tracking Remediation

You do not need a GRC platform. A simple tracking method works - I have used everything from a shared spreadsheet to issues in a Git repository. What matters is recording:

What was found and when
Who is responsible for fixing it
The target remediation date
When it was actually fixed

This creates an audit trail. When someone asks "how do you manage vulnerabilities?" you can show them a documented process with evidence of findings being identified and resolved. That is what auditors and cyber insurers actually want to see.

If you are building out your security monitoring more broadly, a SIEM strategy can help you correlate scan findings with other security events across your environment.

What Free Tools Cannot Do

I am a strong advocate for open source scanning, but I am not going to pretend it covers everything. There are genuine gaps you should be aware of.

Authenticated web application scanning is where commercial tools still have an edge. Nuclei excels at unauthenticated checks, but crawling behind a login page and testing business logic requires tools like Burp Suite Professional or a manual pen test. Budget for an annual pen test from a CREST-certified provider if your organisation handles sensitive data.

Compliance-specific scanning for PCI DSS, ISO 27001 or Cyber Essentials often requires specific tooling or assessor-approved scan providers. OpenVAS can help you prepare, but the official scan needs to come from an approved vendor.

Cloud-native security posture management (CSPM) for AWS, Azure or GCP is not covered by these tools. If you run cloud infrastructure, look at open source options like Prowler (AWS) or ScoutSuite (multi-cloud) to complement your scanning pipeline.

Attack surface management - discovering assets you did not know you had - requires a different approach. Tools like Subfinder and httpx from ProjectDiscovery can help enumerate your external attack surface, but that is a topic for another post.

Getting Started This Week

If you do nothing else, do this:

Install Nuclei on any Linux machine. It is a single binary with no dependencies. Scan your public-facing domains tonight.
Install Trivy and scan your Docker images. You will likely find critical CVEs in base images you have not updated.
Set up a cron job to run both scans daily. Even without fancy reporting, the scan results accumulate and give you a baseline.
Create a simple target list. Every IP address, every domain, every container image. You cannot scan what you have not listed.

You can add OpenVAS and Lynis later once you have the basics running. Start small, automate early, and expand as you build confidence.

If a scan does find something critical and you suspect a compromise, having a ransomware response playbook ready means you are not making decisions under pressure.

The Mindset Shift

The real value of automated scanning is not the tools. It is the shift from reactive to proactive security. Most small IT teams only think about vulnerabilities when something goes wrong - a failed audit, a near-miss incident, a news story about the latest critical CVE.

Running daily scans changes that dynamic. You start each morning knowing the state of your infrastructure. You catch issues before auditors do. You build a track record of proactive security that makes a material difference to your organisation's risk posture.

You do not need a security operations centre to do this. You need a VM, four open source tools and an hour to set up some cron jobs. The hardest part is starting.

Home Lab Network Segmentation: A Practical Guide with VLANs, OPNsense and Proxmox

Daniel Glover — Wed, 01 Apr 2026 13:17:06 +0000

Most home lab guides skip the boring bit. They show you how to spin up containers and virtual machines, but leave everything sitting on a single flat network where your NAS, your experimental Kubernetes cluster and your kids' tablets all share the same broadcast domain. That is fine until your latest Docker experiment gets compromised and suddenly has line of sight to every device in your house.

I run a segmented home lab built on Proxmox and OPNsense. It is not theoretical - it is the network I use every day. This guide walks through exactly how I structured it, why I made the choices I did, and how you can do the same thing over a weekend.

If you want the enterprise version of this conversation, I have written a separate network segmentation strategy guide aimed at IT leaders. This post is the hands-on, home lab version.

Why Bother Segmenting a Home Lab?

The short answer: containment.

A flat network means every device can talk to every other device. Your Proxmox host, your IoT smart plugs, your work laptop and that sketchy container you pulled from Docker Hub last Tuesday all exist in the same trust zone. If any one of them gets compromised, the attacker has unrestricted lateral movement across everything you own.

Segmentation fixes this by creating boundaries. A compromised IoT device cannot reach your NAS. A rogue container cannot scan your management interfaces. Each segment has explicit rules about what traffic is allowed in and out.

Beyond security, segmentation gives you:

Broadcast domain control. IoT devices are notoriously chatty. Isolating them stops mDNS and SSDP noise from polluting your production VLANs.
A realistic test environment. If you work in IT, your home lab should mirror enterprise patterns. Segmented networks with firewall rules are how production environments work.
Traffic visibility. When each VLAN has defined purposes, firewall logs become meaningful. You can see exactly what is talking to what.

The Architecture

Here is the network layout I use. Yours will differ based on your hardware and needs, but the principles apply universally.

VLAN Design

VLAN ID	Name	Subnet	Purpose
1	Management	10.0.0.0/24	OPNsense, switch management, IPMI/iDRAC
10	Trusted	10.0.10.0/24	Personal devices, workstations, phones
20	IoT	10.0.20.0/24	Smart home devices, cameras, sensors
30	Lab	10.0.30.0/24	Experimental VMs, containers, dev work
50	Servers	10.0.50.0/24	Production services - NAS, Plex, Pi-hole
99	Guest	10.0.99.0/24	Guest Wi-Fi, fully isolated

Six VLANs is enough for most home labs. I have seen people create 15 or more and then spend their weekends debugging firewall rules instead of actually using their lab. Start with fewer segments and split later if you need to.

Key Design Decisions

Management VLAN on VLAN 1. Some people insist on moving management off the default VLAN. In an enterprise, I agree. At home, keeping management on VLAN 1 simplifies initial switch configuration since untagged traffic lands there by default. The important thing is that only management devices live on it.

Separate IoT and guest networks. IoT devices need internet access and sometimes local communication with each other (Hue bridges, for example). Guests need internet only. Keeping them separate means you can allow IoT-to-IoT traffic within the VLAN while locking guests down completely.

Lab VLAN with restricted outbound. The lab VLAN has internet access but cannot initiate connections to any other internal VLAN. This is where I run anything experimental. If something goes wrong, the blast radius is contained.

Hardware You Need

You do not need enterprise gear. Here is the minimum:

A VLAN-capable managed switch. Unmanaged switches do not understand VLAN tags. A TP-Link TL-SG108E (around thirty quid) handles eight ports with full VLAN support. If you need more ports or PoE, the Netgear GS308EPP is solid.
A router/firewall that supports VLANs. OPNsense or pfSense running on dedicated hardware or as a VM. I run OPNsense virtualised on Proxmox, which works brilliantly but requires a bit more setup.
VLAN-aware access points (optional). If you want segmented Wi-Fi (and you should), your access points need to support multiple SSIDs mapped to VLANs. UniFi APs do this well. So do TP-Link Omada devices.

Setting Up VLANs on OPNsense

I am assuming you have OPNsense installed and working as your gateway. If you are running it as a VM on Proxmox, make sure the virtual network interface is configured as a VLAN trunk (more on that in the Proxmox section below).

Step 1: Create VLAN Interfaces

Navigate to Interfaces > Other Types > VLAN and create each VLAN:

Parent interface: The physical (or virtual) interface connected to your managed switch
VLAN tag: The ID from your design (10, 20, 30, 50, 99)
Description: Something meaningful - "Trusted", "IoT", "Lab"

Step 2: Assign and Configure Interfaces

Go to Interfaces > Assignments. Each VLAN appears as an available interface. Assign each one, then configure it:

IPv4 Configuration Type: Static IPv4
IPv4 Address: The gateway IP for that subnet (e.g. 10.0.10.1/24 for Trusted)

Enable the interface and save.

Step 3: Configure DHCP

For each VLAN interface, navigate to Services > ISC DHCPv4 (or Kea, depending on your OPNsense version) and enable DHCP:

Range: Leave room for static assignments. I typically use .100 to .200 for dynamic and reserve .1 to .99 for static mappings.
DNS servers: Point to your Pi-hole or Adguard instance if you run one, otherwise use your preferred public DNS.
Gateway: The OPNsense interface IP for that VLAN.

Step 4: Firewall Rules

This is where segmentation actually happens. Without firewall rules, VLANs are just addressing schemes - traffic still flows freely through your router.

My baseline rules follow a simple philosophy: deny everything between VLANs, then allow specific exceptions.

For every VLAN interface, create these rules in order:

Allow DNS to OPNsense. Allow UDP/TCP 53 to the VLAN's gateway IP. Devices need to resolve names.
Allow DHCP. This usually works automatically, but add an explicit allow for UDP 67/68 if needed.
Block RFC1918 to other VLANs. Create a rule that blocks traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. This single rule prevents inter-VLAN traffic without needing to enumerate every subnet.
Allow internet. A default allow rule for traffic destined to non-RFC1918 addresses.

Exceptions I use:

Trusted VLAN can access the Servers VLAN on specific ports (SSH, HTTP/HTTPS, SMB for NAS access).
IoT VLAN can reach specific services on the Servers VLAN (my Home Assistant instance needs to talk to smart devices, so I allow established/related connections back).
Nothing can initiate connections to the Management VLAN except the Trusted VLAN on the OPNsense web UI port.

The order matters. OPNsense evaluates rules top to bottom and stops at the first match. Put your allow rules above the block-RFC1918 rule, or they will never be reached.

Configuring Proxmox for VLANs

If you run Proxmox, you need to tell it about your VLANs so virtual machines land on the correct segments.

Option 1: VLAN-Aware Bridge (Recommended)

Edit your Proxmox network configuration. You want your main bridge to be VLAN-aware:

auto vmbr0
iface vmbr0 inet manual
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 1 10 20 30 50 99

With a VLAN-aware bridge, you assign VLANs per VM in the Proxmox GUI. When creating or editing a VM's network device, set the VLAN Tag field to the appropriate VLAN ID. The VM's traffic is then tagged on that VLAN automatically.

This is the cleanest approach. One bridge, all VLANs, per-VM tagging.

Option 2: Separate Bridges per VLAN

If you prefer explicit separation, create a bridge for each VLAN:

auto vmbr10
iface vmbr10 inet manual
    bridge-ports eno1.10
    bridge-stp off
    bridge-fd 0

This works but gets unwieldy with many VLANs. I moved away from this approach after the fourth bridge.

OPNsense as a Proxmox VM

If OPNsense runs on Proxmox (which I recommend for home labs - one box to rule them all), the setup is:

Pass the physical NIC through to OPNsense as a trunk port on the VLAN-aware bridge with no VLAN tag set. This means OPNsense receives all tagged traffic and handles VLAN routing itself.
Add a second NIC for the WAN interface, either a separate physical port or a bridge connected to your ISP router.
The switch uplink port must be configured as a trunk carrying all your VLAN tags.

This creates a clean architecture where Proxmox handles virtualisation and OPNsense handles all routing and firewalling.

Managed Switch Configuration

Your managed switch needs to know which ports carry which VLANs. The terminology varies between manufacturers, but the concepts are the same.

Trunk Ports (Tagged)

Trunk ports carry multiple VLANs simultaneously using 802.1Q tags. Configure trunk ports for:

The port connected to your OPNsense box (or Proxmox host)
Uplinks between switches
Ports connected to VLAN-aware access points

Access Ports (Untagged)

Access ports strip VLAN tags and present untagged traffic to the connected device. Most endpoint devices (PCs, printers, NAS boxes) connect to access ports assigned to a single VLAN.

For example, your NAS connects to a port that is an untagged member of VLAN 50 (Servers). The NAS sends and receives normal untagged Ethernet frames and never needs to know VLANs exist.

Example: TP-Link Switch VLAN Table

Port	VLAN 1 (Mgmt)	VLAN 10 (Trusted)	VLAN 20 (IoT)	VLAN 30 (Lab)	VLAN 50 (Servers)	VLAN 99 (Guest)
1 (OPNsense)	Tagged	Tagged	Tagged	Tagged	Tagged	Tagged
2 (Desktop)	-	Untagged	-	-	-	-
3 (NAS)	-	-	-	-	Untagged	-
4 (AP)	-	Tagged	Tagged	-	-	Tagged
5-7 (Lab)	-	-	-	Untagged	-	-
8 (Mgmt)	Untagged	-	-	-	-	-

Port 1 is the trunk to OPNsense carrying all VLANs. Port 4 is the trunk to the access point carrying the SSIDs you want broadcast over Wi-Fi.

Testing Your Segmentation

Do not assume it works. Test it.

From a device on each VLAN, try to:

Ping the default gateway. This should work on every VLAN. If it does not, check your interface assignments and DHCP config.
Ping a device on another VLAN. This should be blocked (unless you created a specific allow rule). If pings succeed between VLANs you did not explicitly allow, your firewall rules are wrong.
Access the internet. Every VLAN except Management should have outbound internet access. Management only needs it for OPNsense updates.
Test your exceptions. Can your trusted workstation reach the NAS via SMB? Can your phone reach Home Assistant? Verify every allow rule works as intended.

I keep a simple text file listing every test case and run through it whenever I change firewall rules. It takes ten minutes and has caught misconfigurations more than once.

Common Mistakes

Forgetting to allow DNS. Devices cannot resolve hostnames, so everything appears "broken" even though network connectivity is fine. Always allow DNS to your resolver as the first rule on each VLAN.

Blocking established connections. If you allow Trusted to connect to Servers on port 443, the response traffic needs to get back. OPNsense handles this with stateful firewall rules (it tracks connections automatically), but if you are writing manual rules elsewhere, remember to allow established and related traffic.

Putting the management interface on an accessible VLAN. Your OPNsense web UI, Proxmox console and switch management pages should only be reachable from the Management or Trusted VLAN. Do not leave management interfaces exposed to IoT or Guest.

Over-segmenting. Every VLAN you add is a firewall ruleset you need to maintain. Six VLANs is practical. Twenty is a full-time job. Segment by trust level, not by device type.

Applying This to the Real World

I run this exact setup as both my home network and my test environment for work. When I need to validate a network segmentation strategy before proposing it to the board, I prototype it at home first. When I want to test whether a new privileged access management tool works with segmented networks, I have a safe environment to do it.

The crossover between home lab and professional IT is the real value here. Enterprise segmentation uses the same principles - VLANs, firewall rules, least-privilege access - just at a larger scale with more expensive hardware. If you can segment a home lab, you understand the fundamentals well enough to design or evaluate an enterprise network.

Where to Go from Here

Once your basic segmentation is working, consider these next steps:

Intrusion detection. OPNsense includes Suricata for IDS/IPS. Run it on your inter-VLAN traffic to catch suspicious patterns.
DNS filtering per VLAN. Different Pi-hole or Adguard profiles for different segments. Block ads on Trusted, block everything dodgy on IoT, allow everything on Lab.
Firewall logging and monitoring. Export OPNsense logs to a syslog server or Grafana dashboard. Visibility is the whole point of segmentation.
802.1X authentication. For the truly committed, RADIUS-based port authentication ensures devices land on the correct VLAN automatically based on their credentials.

Network segmentation is not glamorous. Nobody posts their firewall rules on Reddit for upvotes. But it is one of those foundational practices that makes everything else in your home lab more secure, more manageable and more professionally relevant. Get it right once, and you will wonder how you ever ran a flat network.

API Security Best Practices: A Practical Guide for IT Leaders

Daniel Glover — Tue, 31 Mar 2026 06:33:02 +0000

APIs are the connective tissue of modern enterprise architecture. Every microservice, mobile app, SaaS integration and partner connection relies on them. But that ubiquity makes APIs one of the most attractive attack surfaces in your organisation.

Gartner predicted that API attacks would become the most frequent attack vector by 2025 - and they were right. If you are an IT leader who has not yet built a deliberate API security strategy, now is the time.

Why API Security Deserves Board-Level Attention

Most organisations have invested heavily in perimeter security, endpoint detection and identity management. APIs often fall through the cracks because they sit between these traditional domains. They are not a network problem, not purely an identity problem and not an application problem in the traditional sense.

The result is a sprawl of APIs - internal, external, partner-facing and sometimes forgotten - with inconsistent security controls. I have seen organisations with hundreds of APIs where fewer than half had any form of authentication beyond a static API key.

The business risk is real. A single misconfigured API can expose customer data, enable account takeover or allow competitors to scrape proprietary information at scale.

The OWASP API Security Top 10

The OWASP API Security Top 10 is the best starting point for understanding API-specific risks. The 2023 edition highlights these critical vulnerabilities:

Broken Object Level Authorisation (BOLA)

This is the number one API vulnerability for good reason. It occurs when an API endpoint accepts an object identifier from the user but fails to verify that the user has permission to access that specific object. An attacker simply changes the ID in a request to access another user's data.

What to do: Implement authorisation checks on every data access function. Never rely on client-side filtering. Use random, non-sequential identifiers to make enumeration harder.

Broken Authentication

APIs that implement authentication incorrectly - weak token generation, missing token validation, or credentials sent in URLs - are trivially exploitable.

What to do: Use established standards like OAuth 2.0 and OpenID Connect. Implement token expiry and rotation. Never accept API keys as the sole authentication mechanism for sensitive operations.

Unrestricted Resource Consumption

APIs without rate limiting or resource quotas are vulnerable to denial-of-service attacks and cost-based attacks against cloud-hosted services.

What to do: Implement rate limiting per user, per endpoint and per IP. Set maximum payload sizes. Monitor for unusual consumption patterns.

Building Your API Security Strategy

Rather than treating API security as a purely technical exercise, approach it as a governance and architecture challenge. Here is a practical framework.

1. Discover and Inventory Your APIs

You cannot secure what you do not know about. Most organisations significantly underestimate their API count. Shadow APIs - those created by development teams without central oversight - are particularly dangerous.

Start with automated discovery using API gateway logs, network traffic analysis and code repository scanning. Build a living inventory that captures each API's purpose, owner, authentication method, data sensitivity and lifecycle status.

2. Standardise Authentication and Authorisation

Establish organisation-wide standards for API authentication. At minimum:

OAuth 2.0 for user-facing APIs with delegated access
Mutual TLS (mTLS) for service-to-service communication
Short-lived tokens with automatic rotation
Scoped permissions following least-privilege principles

Extend your identity-first security approach explicitly to cover non-human identities including service accounts, API clients and automated workflows.

3. Implement API Gateways as Policy Enforcement Points

An API gateway is your single point of control for cross-cutting security concerns. Use it to enforce:

Authentication - Validate tokens before requests reach backend services
Rate limiting - Protect against abuse and denial-of-service
Request validation - Check payload schemas, reject malformed requests
Logging - Capture every request for audit and anomaly detection

Do not rely on individual development teams to implement these controls consistently. Centralise them at the gateway layer.

4. Shift Security Left

API security testing should happen during development, not after deployment. Integrate these practices into your DevSecOps pipeline:

API specification review - Mandate OpenAPI or AsyncAPI specs and review them for security issues before any code is written
Automated security scanning - Run tools like OWASP ZAP or Burp Suite against API endpoints in CI/CD
Contract testing - Verify that APIs behave according to their specification and reject unexpected inputs
Threat modelling - Include APIs in your threat modelling exercises, focusing on data flows and trust boundaries

5. Monitor and Respond

Runtime API security monitoring is essential because static analysis cannot catch every vulnerability. Focus on:

Anomaly detection - Baseline normal API usage patterns and alert on deviations
Sensitive data exposure - Scan API responses for unintended data leakage
Authentication failures - Monitor for brute force attempts and credential stuffing
Geographic anomalies - Flag API calls from unexpected locations

Common Mistakes I See IT Leaders Make

Treating API keys as secrets. Static API keys are not authentication - they are identification at best. They get committed to repositories, shared in documentation and leaked in client-side code.

Ignoring internal APIs. The assumption that internal APIs are safe because they sit behind a firewall is dangerous. Lateral movement after initial compromise is a standard attacker technique.

Over-exposing data. APIs that return entire database records when the client only needs two fields create unnecessary risk. Design APIs to return the minimum data required.

No versioning or deprecation strategy. Old API versions with known vulnerabilities persist because nobody has a plan to retire them.

A Practical Starting Point

If you are starting from scratch, prioritise these five actions:

Audit your API inventory - Find every API, document its owner and classify its data sensitivity
Deploy an API gateway - Centralise authentication, rate limiting and logging
Adopt OAuth 2.0 - Replace static API keys with token-based authentication for all sensitive APIs
Add API testing to CI/CD - Automate security scanning for every API change
Monitor runtime behaviour - Implement anomaly detection for API traffic patterns

None of these require massive investment. Most can be implemented incrementally alongside existing projects.

The Strategic View

API security is not a one-off project. As your organisation adopts more microservices, integrates more SaaS platforms and builds more partner ecosystems, your API surface will only grow.

The IT leaders who get ahead of this treat API security as a platform capability - something that is built once, maintained centrally and consumed by every development team. Those who treat it as an afterthought will find themselves reacting to breaches that were entirely preventable.

Originally published on danieljamesglover.com

IT Disaster Recovery Planning That Works: A Practical Guide

Daniel Glover — Sun, 22 Mar 2026 07:32:37 +0000

Every IT leader has a disaster recovery plan. Most of them do not work. That is not cynicism - it is what the data tells us. Industry research consistently shows that over 70% of organisations that test their DR plans discover critical gaps.

I have been through enough real incidents to know that the gap between a DR plan document and actual recovery capability is often enormous. The plan says four hours. Reality says four days.

If you are an IT leader responsible for keeping systems running, this guide covers how to build a DR plan that survives contact with an actual disaster.

Why most DR plans fail

The document problem

Most DR plans are documents written once, approved by leadership, and filed away. Within six months, they are partially obsolete because infrastructure changes constantly.

The assumption problem

DR plans are built on assumptions: the network will be available, DNS will resolve, the backup site has capacity, the team will be reachable. Stack them together and you have a house of cards.

I learned this the hard way when a data centre power failure also took out the network equipment we needed to reach our backup site. Nobody had questioned the network connectivity assumption.

The people problem

Disasters happen at 3 AM on a bank holiday weekend when your lead engineer is on a flight. Technical systems can be designed for resilience. People cannot be patched.

Building a DR plan that actually works

A working DR plan is not a document. It is a capability.

Step 1: Define what matters

Classify systems into tiers based on business impact:

Tier 1 - Critical: Direct revenue impact. RTO under one hour, RPO near zero.
Tier 2 - Important: Significant impact but workarounds exist. RTO 4-8 hours.
Tier 3 - Standard: Can tolerate extended outages. RTO 24-48 hours.
Tier 4 - Low priority: Recover when possible.

This forces difficult conversations about what the business actually needs. I have seen organisations classify 80% of their systems as Tier 1, which means nothing is truly prioritised.

Step 2: Map your dependencies

Every system depends on other systems. Draw dependency maps explicitly. Include external dependencies like cloud providers, SaaS tools, and CDNs.

Pay special attention to shared dependencies. If your Tier 1 application and your monitoring system both depend on the same DNS provider, you will lose visibility at the moment you need it most.

Step 3: Design for recovery, not just resilience

Resilience prevents failures. Recovery is what happens when prevention fails. Most organisations over-invest in resilience and under-invest in recovery.

Automated failover for Tier 1. If it requires human intervention, it is not Tier 1 ready.
Documented manual procedures for Tier 2. Step-by-step runbooks a competent engineer who has never seen the system can follow.
Rebuild procedures for Tier 3+. Infrastructure as code and tested restoration scripts.

Step 4: Automate everything you can

Manual recovery procedures are unreliable. People make mistakes under pressure.

Infrastructure as code for rebuilding environments
Automated backup verification (restore and verify, not just check completion)
Automated failover testing in production
Runbook automation over Word documents

Every manual step is a potential failure point.

Step 5: Test relentlessly

Tabletop exercises (quarterly): Walk through scenarios. Cheap and effective.
Component testing (monthly): Test individual recovery procedures.
Full DR tests (biannually): Execute complete recovery. Expensive but essential.
Chaos engineering (ongoing): Introduce controlled failures.

Step 6: Document for humans

Write for the person executing at 3 AM:

Short sentences. Clear instructions. No ambiguity.
Decision trees, not novels.
Contact lists with phone numbers, not just Slack handles.
Version control with Git, not SharePoint.

Step 7: Plan for communication

Communication failures during incidents cause more lasting damage than the technical issues. Include internal templates, external procedures, and status page management.

The cloud does not solve this

Cloud providers offer infrastructure resilience but cannot protect against application-level failures, configuration errors, vendor outages, or account-level issues.

Your cloud DR strategy should include the ability to operate independently of any single provider, at least for Tier 1 services.

Getting started

If your DR plan has not been tested in over a year:

Run a tabletop exercise this month. Pick a realistic scenario and walk through your response.
Test one backup restoration this week. Time it. Verify the data. Compare to your RTO.
Update your contact list today. Remove leavers, add joiners.
Schedule regular testing. Quarterly tabletops, monthly component tests, biannual full tests.

The best time to test your DR plan was six months ago. The second best time is this week.

Originally published on danieljamesglover.com

The IT Skills Crisis: A Practical Framework for Building Your Team

Daniel Glover — Sat, 21 Mar 2026 07:32:43 +0000

Three years ago, I had what I thought was a solid IT team. Strong on infrastructure, reliable on support, capable of keeping the lights on for our e-commerce operation. We had good people doing good work.

Today, that same team composition would leave us dangerously exposed. Not because the people are wrong, but because the skills the business needs have fundamentally changed.

The Ground Has Shifted

Cast your mind back to early 2023. ChatGPT had just launched. Most organisations were still mid-way through cloud migrations. Cybersecurity was important but not yet the board-level obsession it has become.

Now look at where we are:

AI is embedded in operations. Not as a novelty, but as a core tool. Your team needs to understand AI integration, prompt engineering, data pipelines, and governance frameworks.
Cloud is the default. On-premises infrastructure has not disappeared, but the centre of gravity has shifted. Your team needs deep cloud-native skills.
Security is everything. Post-quantum cryptography, zero trust architecture, supply chain security, AI-powered threat detection. The security skills gap has widened enormously.
Automation has eaten the routine. Ticket routing, user provisioning, monitoring response, patch management. If your team is still doing these manually, you are paying human rates for robot work.

The traditional IT operations role is being compressed from both sides. Automation handles the routine. Specialist skills are needed for the complex work. The middle ground is shrinking fast.

The Roles That Have Changed

The Traditional Sysadmin

Three years ago, we had dedicated system administrators managing on-premises servers. Today, most of that infrastructure runs in the cloud. A sysadmin who cannot write Terraform or navigate Kubernetes is increasingly limited in what they can contribute.

The Helpdesk Technician

First-line support has been transformed by AI-powered service desks, self-service portals, and automated resolution workflows. The role has morphed into something closer to customer experience and technical problem-solving. Soft skills and analytical thinking matter more than knowing how to reset a password in Active Directory.

The Network Engineer

Software-defined networking, cloud-native networking, and zero trust architectures have transformed what it means to manage a network. Traditional knowledge of switches, routers, and VLANs is still valuable, but it is no longer sufficient.

The New Hybrid Roles

What has emerged are hybrid positions that blend disciplines:

Cloud Security Engineer - combining infrastructure, cloud, and security expertise
DevOps/Platform Engineer - bridging development and operations with automation
AI Operations Specialist - managing AI model deployment, monitoring, and governance
Identity and Access Management Specialist - as zero trust makes identity the new perimeter
Data Engineer - managing the pipelines that feed both business intelligence and AI

These roles did not exist in most IT departments three years ago. Now they are critical.

The Retraining vs Hiring Dilemma

Do you retrain your existing team or hire new people? The honest answer is both.

The Case for Retraining

Your existing team knows your business. They understand your systems, your culture, your customers. That institutional knowledge cannot be replicated by a new hire. Retraining is also significantly cheaper - the average cost of replacing a technical employee is typically one to two times their annual salary.

The Case for Hiring

Some skills gaps are too wide to bridge through training alone. If you need a senior cloud architect and your most experienced infrastructure person has never worked outside on-premises environments, that is a two to three year development journey.

My Approach: The 70/30 Rule

In our team, I work roughly to a 70/30 split. Seventy per cent of our skills gap is addressed through retraining and upskilling. Thirty per cent requires strategic hiring for critical capability gaps we cannot develop fast enough internally.

Building a Skills Matrix

Before you can close the gap, you need to see it clearly.

Step 1: Define the Skills You Need

Start with your technology strategy, not your current team. For us, that produced five priority areas:

Cloud-native infrastructure (Azure, AWS, IaC, containers, serverless)
Cybersecurity (zero trust, threat detection, incident response)
Automation and DevOps (CI/CD, scripting, platform engineering)
AI and data (AI integration, data pipelines, ML operations)
Leadership and communication (vendor management, stakeholder communication)

Step 2: Assess Current Capabilities

Use a four-point scale:

Awareness - understands the concept but cannot execute
Developing - can execute with guidance
Competent - can execute independently
Expert - can lead others and handle complex scenarios

Involve team members in the assessment. They often have the most accurate view of their own capabilities.

Step 3: Map the Gaps

Plot current capabilities against required. The gaps become immediately visible.

Step 4: Build Individual Development Plans

Align organisational needs with individual motivation. Forcing someone into a role they have no interest in is a recipe for poor outcomes.

The Practical Framework for Upskilling

Dedicated Learning Time

We allocate one half-day per fortnight as protected learning time. No tickets, no meetings, no interruptions. This sounds expensive. It is. But it is cheaper than hiring replacements when your team leaves because their skills are stagnating.

Certification Pathways

We fund relevant certifications for every team member, typically two per year. Current priorities: Azure/AWS cloud, CompTIA Security+ and CySA+, Terraform and Kubernetes, and emerging AI certifications.

Project-Based Learning

The most effective learning happens on real work. I deliberately assign stretch projects that push people into their development areas. This requires accepting that things will take longer. That is the investment.

Mentoring and Knowledge Sharing

We run fortnightly technical sessions where team members present what they have learned. Where we have hired specialists, part of their role is explicitly to mentor and upskill existing team members.

The Human Side

Skills matrices and development plans are the easy part. The hard part is the human element. Some team members will resist change. Some will feel threatened. The key is honest, compassionate communication about where the industry is heading, combined with genuine investment in helping people get there.

The IT skills crisis is real. But it is not insurmountable. The leaders who invest in their teams now will have a significant competitive advantage. Those who ignore it will find themselves constantly hiring, constantly onboarding, and never quite keeping up.

Originally published on danieljamesglover.com