The Truly Unlimited Technology Framework
Technology, managed across every layer of your business.
Business can only grow as much as your technology can handle it. That's not a slogan we put on a wall. It's the reason this framework exists. Every business we work with eventually runs into the same wall: the work outgrows the systems underneath it. This page explains how we think about those systems, layer by layer, and how we manage them so the wall shows up later — or not at all.
Don't understand all of this? That's our job.
What is complete technology management?
Complete technology management means one team is accountable for every layer your business runs on — the cabling and power in the building, the internet and the network, the computers and servers, the backups, who can log into what, the security and compliance controls, the software your team works in every day, the AI tools now sitting alongside them, and the plan for what comes next.
Most IT providers manage a slice of that list and refer out the rest. We treat the whole list as one system, because that's how it behaves when something breaks.
Your operations do not run on computers alone. They run on a chain of dependencies, and the chain is only as useful as its weakest link. A perfect laptop policy doesn't help you if the cable run to the second floor was never terminated properly. A strong firewall doesn't help you if four people share one login. We built this framework so nothing in that chain is somebody else's problem.
Nine layers
From the physical building to business strategy.
One standard
Applied the same way whether you have twelve people or fifty.
Plain English
You don't need to know what any of this means to benefit from it.
How is managed IT different from computer support?
Computer support fixes the device in front of you. Managed IT takes ongoing responsibility for the environment that device lives in — the network it connects to, the identity it logs in with, the data it touches, the backups behind it, and the controls that keep all of that defensible. Support is reactive by design. Management is continuous by design.
What we provide is not antivirus on your computers while we wait for something to break. That model made sense when a business's technology was a handful of PCs and a printer. It doesn't describe how a service business runs today.
Here's what typically happens instead. A company grows to twenty or thirty people. Along the way it picks up a phone system, a cloud file share, an accounting platform, a scheduling tool, a camera system, a badge reader, a couple of vendor portals, and a growing pile of logins.
Each piece was bought separately and works fine on its own. Nobody owns the space between them. So when something goes wrong — and it always shows up as "the internet is slow" or "I can't get into the file" — three vendors each confirm their part is working, and the person who ends up holding it together is whoever in the office is least afraid of technology.
That's the gap. Not a lack of tools. A lack of anyone accountable for the whole.
Nine layers, one system
We borrowed the shape of this from the OSI model — the layered way networks have been described for decades — and extended it to cover everything a business actually depends on. Each layer sits on the one below it. Each one answers a business question, not just a technical one.
Select a layer to expand it.
- Structured cabling
- Fiber
- Network drops
- Racks
- Patch panels
- Power and UPS
- Surge protection
- Cooling
- Wireless hardware
- Cameras
- Door access control
- Physical network design
- Building connectivity
- Low-voltage systems
- Device placement
Is the environment physically ready to support the business being built on top of it?
- Internet connectivity
- Redundancy and failover
- Routing
- Switching
- Firewalls
- Wireless networks
- VLANs
- VPN
- SD-WAN where appropriate
- Multi-site connectivity
- Segmentation
Can everything connect reliably without exposing everything to everything else?
- Workstations
- Endpoints
- Mobile devices
- Servers
- Virtualization
- Virtual desktops
- Cloud infrastructure
- Azure
- Storage
- Printing
- Patching
- Device lifecycle
Can the technology environment carry the current workload and the next stage of growth?
- Monitoring
- Backup
- Disaster recovery
- Failover
- Business continuity
- Patch management
- Preventive maintenance
- Capacity planning
- Recovery testing
- Incident response readiness
When something fails, how quickly can the business recover, and what evidence proves it?
- Microsoft Entra ID
- Active Directory
- Single sign-on
- Multi-factor authentication
- Conditional access
- Least privilege
- Role-based access
- User onboarding and offboarding
- Service accounts
- Privileged access
- Session controls
Is every person, device, application and automated system verified before receiving access?
- NIST-aligned practices
- Zero Trust principles
- Endpoint protection
- Vulnerability management
- Encryption
- Logging and monitoring
- Security awareness
- Risk assessments
- Written information security programs
- Compliance readiness
- Policy and evidence
- Incident response planning
- Vendor risk
Is security built into the environment, or added only after something goes wrong?
- Microsoft 365
- Line-of-business applications
- CRM
- File systems
- Collaboration tools
- Business software
- Workflow design
- Integrations
- Automation
- Licensing
- Reporting
Do the systems make work easier, clearer and more consistent, or do employees work around them?
- AI agents
- Large language models
- Knowledge systems
- AI workflows
- Data permissions
- Human review
- Audit trails
- AI governance
- Secure system access
- Model and vendor evaluation
What can AI safely do, what should it never do alone, and how will the business know the difference?
- Technology roadmap
- Budget planning
- vCIO
- Vendor management
- Efficiency planning
- Growth planning
- Acquisition readiness
- Risk prioritization
- Quarterly reviews
- Executive reporting
What business result is the technology supposed to create or protect?
No layer stands alone. A decision in one shows up in another — which is the entire reason we manage them together.
Read through the nine and one of them probably stood out. The assessment walks the same layers and tells you where yours actually stand.
Business IT Health AssessmentWe didn't invent the ideas. We applied them.
OSI
Helps us think in layers.
NIST
Helps us govern risk across those layers.
Zero Trust
Helps us verify access across those layers.
The TU Standard
Defines how those ideas are applied to a real business.
How does the OSI model relate to business technology?
The OSI model is a seven-layer description of how network communication works, and it's been the common language of networking for decades. We use its shape, not its contents.
The useful idea is that a system is easier to understand, troubleshoot and improve when you separate it into layers that each depend on the one beneath. We applied that thinking to an entire business environment rather than to a single network connection.
To be clear about what this is: our framework is our own, and it is not an official extension of the OSI model.
What does NIST mean for a small business?
NIST is the U.S. National Institute of Standards and Technology. Its Cybersecurity Framework organizes security work into functions — govern, identify, protect, detect, respond, recover — that give a business a structured way to talk about risk instead of a list of products.
For a small business, NIST is most valuable as a way to answer "are we actually covering this?" rather than as a compliance obligation. NIST doesn't require every item we list in this framework; we use its structure because it's clear, public, and widely understood.
What is Zero Trust?
Zero Trust is a security approach, not a product you buy. Its premise is that being inside the network isn't proof that you should be trusted. Access gets verified explicitly, users and systems get only the privileges they need, and the environment is designed on the assumption that something will eventually be compromised.
In practice that looks like multi-factor authentication, tight permissions, segmentation and continuous monitoring — applied across every layer, not just at the front door.
Applied across every layer
- Govern
- Identify
- Protect
- Detect
- Respond
- Recover
- Verify explicitly
- Use least privilege
- Assume compromise
- Monitor continuously
Primary sources: NIST Cybersecurity Framework · NIST SP 800-207, Zero Trust Architecture
Where the technology framework came from
My first IT job was at a company called CM Computers. It later evolved into HiTech Networks, which today is a low-voltage partner we work with on projects — so the people I started out around are still people I build with.
What stuck with me from those early years wasn't a piece of technology. It was a pattern. People didn't care about their data until something went wrong. Then they cared about nothing else. And this was the same stretch of time when breaches stopped being an abstract idea and started showing up in the news with names and dates attached.
Watching those two things at once — how little attention the risk got beforehand, and how total the attention was afterward — is what turned a job into an obsession. Technology, then security, then how attacks actually work, then business, and eventually AI.
Later I learned there were formal standards and frameworks for all of this. Not opinions — documented, structured ways to organize security and operations. And in corporate environments I got to see what that looks like when it's running properly: security accounted for, systems accounted for, reporting, standards, controls, and the operational effort behind them, all fitting together in a way that was organized instead of improvised.
I did not want small businesses to receive a watered-down version of technology management. I wanted to bring them the same discipline, visibility, reporting, and protection that larger organizations build into their operations, then make it practical enough to use every day.
That last part matters as much as the first. A framework nobody can use isn't discipline, it's paperwork. So this one is built to be run, not filed.
We want to be the bridge between enterprise-level technology discipline and the small businesses that deserve access to it.
If that's the way you'd want your technology handled, the fastest way to find out whether it fits is a conversation.
Schedule a ConversationWhy should AI be treated as its own technology layer?
Because AI doesn't behave like software. It behaves like an automated end user. It has access, responsibilities, workflows, memory, connections into your systems, and a defined job. Anything that fits that description belongs in your identity model, your security model and your documentation — not in a list of features.
Think about what you'd do before handing a new hire the keys. You'd decide what they can see, what they can approve, what they need to escalate, where their work gets reviewed, and what happens on their last day. Almost nobody asks those questions before connecting an AI tool to their email, their files or their customer records.
That's the whole argument. When AI is treated as a feature, it quietly accumulates access nobody scoped and produces output nobody checks. When it's treated as a layer, it gets the same treatment as everything else in this framework: defined permissions, defined boundaries, defined review points, and a policy that says what it's for.
Access
What data can it reach, and what is deliberately out of scope?
Responsibility
What is it allowed to do on its own, and what needs a person?
Memory
What does it retain, where does that live, and who else can see it?
Review
Who checks the output, and how often?
More on how we deploy AI → TU AI
Where each layer lives in our work
The framework isn't a diagram we keep separate from the business. It's how the work is organized. A few of these names are framework categories describing how we group the work, rather than finalized brands.
Explore the established service lines: TU IT Services · Compliance · AI · Projects & Technology
What is the difference between managed services and an IT project?
Managed services maintain the environment. Projects change the environment. Strategy decides what should change and why. Ongoing management covers the day-to-day: monitoring, patching, support, security, backups, user changes, vendor coordination. A project is work that falls outside those normal expectations — building something new, adding or removing something significant, or concentrated effort well beyond routine support.
Ongoing management typically includes
- Monitoring and maintenance
- Support requests and troubleshooting
- Patching and updates
- Security controls and alerting
- Backup verification
- User onboarding and offboarding
- Vendor coordination
- Documentation and reporting
Projects typically include
- New office builds and relocations
- New infrastructure and cabling
- Server deployments
- Cloud and platform migrations
- Camera and access-control installations
- Large-scale redesigns or replacements
- Significant additions or removals
- Concentrated work beyond routine support
As a general rule, new installations, additions, removals, migrations, and concentrated work that extends beyond normal support are scoped as projects. Exceptions may vary based on the service agreement and situation.
We'd rather tell you which category something falls into before the work starts than have that conversation afterward.
See how we scope project work → Projects & Technology
What does vendor agnostic mean in IT?
Vendor agnostic means the standard comes first and the product comes second. We're not locked into one manufacturer, one platform or one reseller relationship, so the question we ask is what the layer needs to accomplish — then we choose what meets it. If a tool you already own meets the standard, the right answer is to keep it.
Products change. Vendors change. The standard should survive both. Platforms get acquired. Licensing models get rewritten. A product that was the obvious choice three years ago sometimes isn't anymore. If your technology approach is built around a specific vendor, every one of those changes becomes your problem to absorb.
We also work alongside vendors you already have, and that's normal — your phone provider, your internet carrier, your low-voltage contractor, your line-of-business software vendor. Good vendor relationships are an asset. Our role isn't to displace them; it's to make sure the layers connect and somebody is accountable for the result.
Related → Certified Technology
What this looks like when it's working
None of this is worth much as a philosophy. It's worth something when the business feels different.
Fewer surprises
Problems get caught in monitoring and reporting instead of in a phone call from a frustrated employee.
Faster answers
When something breaks, there's no round of vendor finger-pointing, because one team already knows how the pieces connect.
Growth that doesn't stall
Opening a location, adding a team, or moving offices becomes a planned project instead of an emergency.
Security you can demonstrate
Documentation, controls and evidence exist before a client questionnaire, an insurance application or an audit asks for them.
Decisions with context
Budget and roadmap conversations happen with real information about what you have and what it's costing you.
Less on you
The owner or office manager stops being the unofficial IT department.
Why does physical infrastructure matter to cybersecurity?
Because access is physical before it's digital. An unsecured network closet, an unlabeled live drop in a public area, a door held open by a wedge, or a camera system on the same flat network as your file server all create exposure that no software control fully compensates for. Asking whether the physical layer matters is like asking a builder whether the foundation matters. Whatever you build on will have consequences as you scale.
Not sure which layer needs attention first?
That's usually the honest starting point, and it's a fine one. The assessment walks through your current environment layer by layer and shows you where you actually stand — no obligation, and no requirement that you understand any of the terminology on this page.
Don't understand all of this? That's our job.