What does CTS Companies do?

CTS Companies is a Michigan-based Managed IT Services Provider delivering managed IT, cybersecurity, cloud, and network infrastructure for SMBs.

Where does CTS provide services?

Primarily Southeast Michigan and the broader Michigan market, with projects across the Midwest.

Do you support Microsoft 365?

Yes. CTS deploys, migrates, and manages Microsoft 365, Azure AD identity, SharePoint, OneDrive, and compliance/backup policies.

CTS Field Notes: IT, Security & AI Insights

For many small businesses, AI feels both important and frustratingly vague.

Owners and managers hear constantly about what AI is capable of. They see demonstrations, read headlines, and watch larger companies invest heavily in it. But the practical question is much harder:

How do we actually figure out where AI fits in our business?

For a small business, that usually requires bringing together three things:

Knowledge of the business. Knowledge of AI. The ability to implement.

The problem is that those three things rarely exist in the same place.

Broadly, I think small businesses have three ways to approach the problem.

1. Figure it out internally

The first option is to learn about AI yourself and look for opportunities inside the business.

This approach has one major advantage: you know your business better than anyone else.

You know which processes are inefficient, what employees spend too much time doing, where customers get frustrated, and which tasks have always been harder than they should be. An outside person may need weeks of conversations just to uncover things that are obvious to you.

The challenge is AI knowledge.

Someone inside the company has to understand enough about what AI can do to connect those business problems with possible solutions. Then someone has to actually build, configure, integrate, and maintain whatever you decide to use.

For a 20-, 50-, or even 100-person company, that can be difficult. There may not be anyone whose job it is to experiment with AI, and the people capable of doing it usually already have plenty of other responsibilities.

Advantages: Deep knowledge of your own business, greater flexibility and control, and the potential to create something highly specific to the way you operate.

Tradeoffs: Requires time, curiosity, AI knowledge, technical ability, and someone willing to own the project through implementation.

2. Bring in outside AI expertise

The second approach is to hire someone to help.

A good consultant or outside firm can bring something most small businesses don’t have internally: a broader understanding of what AI can currently do.

They may have seen similar problems in other companies and can help identify opportunities you wouldn’t have recognized yourself.

But the knowledge imbalance works in the opposite direction.

They understand AI. You understand your business.

So a significant part of the process becomes transferring enough knowledge about your company to the outside firm for them to make useful recommendations.

There is also an important distinction between identifying an opportunity and implementing it.

It is relatively easy to produce a list of ideas for how a company might use AI. It is much harder to redesign a workflow, connect systems, train employees, handle security concerns, and make the new process actually work every day.

That doesn’t make consulting a bad approach. It just means businesses should understand what they’re buying. A strategy report and a working solution are very different things.

Advantages: Access to AI expertise, outside perspective, and potentially much faster identification of useful opportunities.

Tradeoffs: Cost, the time required to teach someone your business, and the possibility that implementation becomes a much larger project than identifying the idea.

3. Use something someone else has already figured out

The third path is increasingly interesting: use a packaged AI-enabled product or service.

This could be entirely new software, an AI-enabled service, or simply a new capability inside software you already use.

In this case, someone else has already done much of the work.

They identified a specific problem. They determined how AI could help solve it. And, importantly, they built a product or service you can evaluate. You still have to check its fit, data handling, integrations, and implementation requirements.

Instead of asking:

“How could we use AI to solve this?”

you’re asking:

“Is this already-solved problem important to our business?”

That’s a very different question.

Imagine a product built specifically to automate one narrow accounting, customer service, sales, legal, or administrative workflow. The company behind it doesn’t need to understand everything about your organization. It needs to understand that particular problem extremely well.

If the problem matches yours and the product works as claimed, much of the difficult AI work may already have been done.

Potential advantages: Faster adoption, easier implementation, lower internal expertise requirements, and lower cost than building something custom, depending on the product and workflow.

Tradeoffs: Less customization and control. You’re largely accepting someone else’s definition of the problem and their way of solving it. And, of course, the solution is only valuable if the problem it solves is actually important to your business.

There isn’t a universally right answer

These three approaches aren’t mutually exclusive.

A company might use packaged AI tools for several straightforward functions, work internally on something unique to its business, and bring in outside expertise for a particularly complicated opportunity.

And each approach involves tradeoffs.

The table is a rough comparison, not a promise about any particular project. Integration, sensitive data, and unusual workflows can change the cost and effort.

Approach	Business Knowledge	AI Knowledge	Implementation Effort	Customization	Typical Speed
1. Figure it out internally	High	Must develop internally	High	High	Slower
2. Bring in outside expertise	Must be transferred	High	Medium to high	High	Medium
3. Use a packaged solution	Needed mainly to judge fit	Built into the solution	Lower	Lower	Faster

The ideal situation would be someone who understands your company deeply, understands the rapidly changing capabilities of AI, and can implement the solution economically.

For most small businesses, that person or team doesn’t exist.

So the more useful question may not be:

“What should our AI strategy be?”

It may be:

“Which parts of this do we want to figure out ourselves, which parts should we get help with, and which problems has someone else already solved for us?”

For many small businesses, answering that question is probably a much more practical place to start.

Before You Change HVAC Contractors

When you replace an HVAC contractor, put the building’s login credentials on the handover list alongside maintenance records, warranties, and the date of the next service visit.

Ask the outgoing company to identify every way it can reach the system. That might include a manufacturer’s portal, a remote connection to a computer in the building, or an administrator account used by its technicians. Find out who controls those accounts and what has to happen for the incoming contractor to take over.

Do this while everyone is still answering the phone.

A contractor change is a useful time to work through these details because the people involved have an immediate reason to cooperate. Someone needs to accept responsibility for the equipment. Someone needs to demonstrate that it works. Access belongs in that conversation.

Find out whose account it is

Consider a possible arrangement: a contractor installed a heating-control system several years ago and registered the management portal using an employee’s email address. The customer pays for the service and owns the equipment, but password resets go to the contractor’s employee.

The arrangement may have worked perfectly well. Trouble begins when the employee leaves, the contractor changes, or the customer needs to make an adjustment without calling for help.

Before the handover, establish whether the business has its own administrator access, who receives recovery messages, and whether the manufacturer requires a formal transfer. Ask the incoming contractor to explain any account or subscription it expects to control.

A leased building adds another conversation. The property manager may own the system, while the tenant depends on its operation. In that case, the tenant needs a named contact, an escalation route, and a clear account of who can authorize changes. Buying another service contract will not settle those responsibilities.

The same exercise applies to badge readers, cameras, alarm notifications, and environmental monitors. Each may have a different installer, portal, and support arrangement. Start with the systems whose failure would interrupt work or affect access to the building.

Test the handover before closing it

A list of usernames is a poor substitute for watching the new arrangement work.

Have the incoming provider demonstrate an authorized routine task with the person responsible for the building. Depending on the equipment, that could mean reviewing a schedule, retrieving a configuration backup, or checking where a notification goes. Confirm that the business can reach support and that recovery messages arrive at an address it controls.

Then review the old access. Individual accounts, shared credentials, remote-support software, and manufacturer permissions may need different treatment. A password change in one portal does not tell you whether a separate remote connection remains available.

Coordinate removals with the people responsible for operating the equipment. Abruptly disabling an account can create its own problems if it supports an integration or an essential service. Record what was removed, what remains, and the reason for any temporary exception.

NIST’s September 2026 draft of its Guide to Operational Technology Security provides context for this work. It includes building automation and physical-access systems within operational technology and addresses security alongside the equipment’s reliability and safety requirements. The draft also expands guidance on asset management and protection of system-management functions. It remains a draft open for public comment.

For a smaller business, a contractor handover is a manageable opportunity to put that thinking into practice. Facilities knows how the equipment behaves. The contractor knows how to service it. IT can help examine accounts, authentication, and network access. Bring those people together around a specific system and a specific change.

Keep the resulting record with the service agreement. Include the equipment and location, account owner, support contacts, access methods, and the date the transfer was tested. Store passwords in the organization’s approved password manager.

Before closing the job, ask the person responsible for the building to explain what they would do if the system stopped responding tomorrow morning. They should be able to find the right contact, reach the necessary records, and describe any approved manual fallback. If the answer still depends on calling the former contractor, there is another item to finish.

NIST SP 800-82 Rev. 4, Guide to Operational Technology Security, initial public draft

A security team can truthfully say a patch is deployed and still have important work left to do.

That sounds obvious until an incident update arrives with the reassuring word remediated. The word is doing several jobs at once. It can mean the vulnerable code changed. It can mean the change reached production. It can mean old data was removed. It can mean someone looked for evidence that the flaw was used. Those are related facts, but they are not interchangeable.

Cloudflare’s September disclosure of a cross-tenant data-exposure vulnerability in its Containers product is a useful recent example. The company said a researcher reported the issue through its bug-bounty program, that it fully remediated the vulnerability, and that it had no evidence customer data was compromised. The technical details matter to affected users. The management lesson is broader: a sound closure statement has to answer more than “did we ship a patch?”

The four questions hidden inside “fixed”

First: What changed? A remediation begins with a specific control, code path, configuration, or process change. Vague language makes it impossible for another person to judge whether the stated fix addresses the actual condition.

Second: Where is the change active? A fix in a repository, a staging environment, or a newly created tenant is not automatically a fix everywhere it needs to be. Rollout status should name the scope: production systems, regions, versions, integrations, or other boundaries that matter.

Third: What legacy state remains? Some problems leave behind old snapshots, caches, tokens, records, permissions, or derived data. A code correction can stop a condition from recurring without changing material that already exists. Cleanup is its own workstream, with its own evidence.

Fourth: What did the review find? “No evidence” is not the same as “it definitely never happened.” It is a statement about the evidence available after a defined investigation. That is honest language when it is paired with the scope and method of review rather than used as a magic eraser.

Turn a status update into a decision record

For a smaller organization, the practical artifact can be a short table: condition, owner, systems in scope, action taken, verification performed, remaining uncertainty, and next review date. It is not bureaucracy for its own sake. It prevents a future investigator, auditor, or new technology partner from having to reconstruct what “fixed” meant in a rushed meeting.

It also makes escalation clearer. A rollout gap belongs with the deployment owner. A retained backup or log question belongs with the owner of that service. A question about possible exposure belongs with the people who can examine evidence, not with the person who happened to apply the patch. One label should not erase those handoffs.

Why this matters outside a cloud provider

Most organizations will never investigate a container-storage flaw. They will, however, replace a compromised account, revoke a vendor connection, patch a server, close an exposed share, or change a payment process. Each action can produce a premature feeling of completion.

The better closing question is not simply, “Was the fix applied?” It is, “What condition stopped, what old state was checked or removed, and what evidence supports our conclusion about impact?”

That question is useful because it assigns work. The person who deploys a patch may not own backup retention. The person who revokes a credential may not own audit logs. The person who communicates with leadership may need a clear boundary between verified facts and remaining uncertainty.

A completed patch is good news. It just should not be asked to carry the whole meaning of recovery, accountability, or future confidence over time.

The Invoice Is Not the Test

A professional-looking invoice lands in an inbox. It has the right tone, a familiar logo, perhaps even a name someone recognizes. The first question is usually visual: does this look legitimate?

That question is understandable, but it is not the one that protects a business. The better question is: does this request belong in an expected business process?

Modern phishing is often designed to pass a quick visual inspection. A convincing invoice, a security notice, or an urgent executive request may look entirely ordinary. The useful defense is not becoming a forensic email analyst before lunch. It is having a simple way to verify an unusual request without relying on the request itself.

Verification should use a path the request does not control

The common thread is simple: use a known route outside the email, text, or call that created the urgency. A process that relies on replying to the same message, clicking the same link, or calling the phone number supplied by the requester is not really independent verification.

Invoice or payment request: Confirm through a known vendor contact, vendor portal, or independently verified phone number—not the email thread.
Security alert: Open the actual product or service directly through a bookmark, app, or known URL. Do not use the alert’s link to find out whether the alert is real.
Payment-detail change: Require out-of-band confirmation with a known contact before changing banking information. FBI IC3 guidance specifically recommends a secondary channel for account-information changes.
Account-access request: Treat unexpected permissions, password resets, MFA changes, and device enrollment as high-risk events that need an owner and an independent check.
Urgent executive request: Confirm through a second channel before money, credentials, or sensitive data move. Urgency is a reason to verify faster, not a reason to skip verification.

This is less glamorous than teaching people to spot a suspicious font. It is also more durable. Brand styling changes. Attackers improve their writing. A known verification path remains useful.

Examples worth recognizing now

Several patterns are especially worth putting on a short “pause and verify” list: fake vendor invoices and payment-change notices; counterfeit security alerts using familiar product names; consent requests that open a real Microsoft or Google permission screen; and executive, support, or authority impersonation that leans on urgency. The goal is not to assume every unexpected message is malicious. It is to recognize the requests that should not be completed on trust alone.

The consent-request example deserves special attention. FBI IC3 warned in September that malicious actors can use OAuth consent phishing to direct a user to a legitimate provider’s permission screen for an application the attacker controls. If the user approves broad access, the attacker may obtain account access without stealing the password or defeating MFA. A real sign-in page is not proof that the requested application is safe.

AI raises the same underlying problem. It can help impersonators make a message, call, or video seem more persuasive, but it does not change the response: verify identity and the requested action through an independent route. IC3’s recent impersonation warnings emphasize that urgency, spoofed identities, and new technologies can be used to manufacture credibility.

A low-friction verification habit is a security control

The practical goal is not to make employees afraid to act. It is to make the safe action easy. A company should know who can verify a vendor payment change, where staff should check a suspicious service alert, and which second channel is available when a senior person sends an unexpected request.

That is a better security program than asking everyone to trust their instincts. An invoice is not the test. The test is whether the request survives the normal business process that was already supposed to protect the company.