I.How we think
1Why don't you always recommend the obvious industry-standard answer?
Because 'standard' and 'correct' are not synonyms.
We absolutely believe in standardization—it is one of the foundations of a supportable environment. But a standard should be the end of a decision process, not the substitute for one.
- We ask what problem is actually being solved, not simply what product category is being requested.
- We compare architecture, operational burden, recoverability, licensing, vendor behavior and long-term support—not just the purchase price.
- We are willing to revisit a prior standard when the market changes materially.
- We do not believe clients should inherit platform inertia simply because changing would be inconvenient for us.
We standardize aggressively—but only after the standard has earned our confidence.
2Do you really do your own R&D?
Yes. And by R&D we do not mean reading a vendor comparison chart.
When a decision matters, we may build it, test it, break it, document it and live with it long enough to understand the awkward parts before we ask a client to depend on it.
- When VMware's economics changed, we did not reflexively replace it with the next familiar logo. We invested roughly 280 hours investigating the practical alternatives and ultimately selected Proxmox for the use cases we were solving.
- In AI, we did not stop at enabling a generic assistant. We built and operated local RAG systems, tested open- and closed-model approaches, worked through ingestion and retrieval problems, deployed Claude-based workflows, and built custom applications.
- We periodically re-evaluate major third-party platforms and suppliers—typically on a multi-year cycle, sooner when technology or vendor economics move faster than that.
- Sometimes that research confirms the incumbent. Sometimes it tells us to move. The important part is that the answer is evidence-driven.
3What does 'production ready' mean to you?
Something working once is not the same thing as something we are prepared to depend upon.
A demo can be impressive. A successful installation can be encouraging. Neither, by itself, tells us whether the system will behave sensibly at 2:00 a.m., during a restore, after a vendor update, or when the one person who understands it is on vacation.
- Can it be monitored?
- Can it be restored?
- Can another engineer understand and support it?
- Are permissions and administrative paths intentional?
- Do we know the failure modes?
- Is there a rollback or recovery path?
- Is the documentation good enough that six months from now we still know why we made the decision?
We do not confuse working code with reliable software—and we apply the same rule to infrastructure, security and AI.
4Are you an MSP, an engineering firm, or a technology advisor?
All three, depending on what the problem requires.
The managed-services work matters because it keeps us close to the operating reality of a business. The architecture work matters because today's helpdesk fix can become tomorrow's structural problem. The advisory work matters because sometimes the correct answer is not a technical project at all.
- Managed technology: keep the environment healthy, secure, patched, monitored and recoverable.
- Architecture and engineering: design migrations, platforms, networks, cloud systems, software and AI capabilities.
- Technology counsel: help leadership understand tradeoffs, timing, risk and what not to do yet.
- Independent review: challenge assumptions before something fragile becomes production.
II.How we work with clients
5Why do you insist that clients own the technology the business depends on?
Because it is your business—not ours.
Domains, Microsoft 365 subscriptions and other material business systems should be registered to the client wherever practical. You should retain administrative authority. We receive the access necessary to do our job; we do not want ownership to become leverage.
- You should be able to revoke our access.
- You should not need our permission to prove that an account, domain or tenant belongs to you.
- If you sell the company, change providers or bring IT in-house, the transition should be an engineering exercise—not a hostage negotiation.
- Some MSP-only security and management tools necessarily sit under our master agreements; those are handed off or replaced in an orderly transition.
Our job is to make ourselves valuable—not unavoidable.
6Why don't you sell everyone 'all-you-can-eat' support from day one?
Because unlimited is not free. Somebody pays for it.
Before we know how an organization actually uses support, an unlimited price forces us to do one of two things: guess high or accept an unknown amount of work. Guessing high means the quiet, self-sufficient client subsidizes the client who calls four times a week. Guessing low eventually creates pressure for the provider to rush work, narrow the definition of 'included,' or renegotiate from frustration.
We would rather learn the operating pattern first.
- If your systems are stable and you rarely need help, we do not want to charge you for a large helpdesk allowance you never consume.
- If you consistently use two, three or four hours of support every month, then a broader fixed-price plan starts to make sense because it removes month-to-month surprises.
- If an environment permanently requires twice the engineering effort assumed in the agreement, we should talk about it rather than pretending nothing changed.
Fairness should work in both directions.
7What does reciprocity mean in a technology relationship?
It means neither side treats the agreement as a loophole.
We absorb normal operating variation. One month can be heavier than another. A backup agent breaks; Microsoft changes a security control; firmware becomes troublesome; something takes longer than expected. We do not want every extra hour to become an invoice.
In return, the client participates in keeping the environment supportable.
- Reboot when updates actually require a reboot.
- Respond when we need a decision or access window.
- Maintain supported hardware and software.
- Follow agreed security practices.
- Tell us when the business changes rather than letting scope quietly double.
- Treat our engineers like partners—and expect the same professionalism from us.
Fixed price absorbs normal operating variation inside a defined boundary. It does not erase the boundary.
8Will you tell us when we're creating our own problem?
Yes—politely, but yes.
Sometimes support cost is not caused by bad technology. It is caused by operating behavior: a machine that is never rebooted, unsupported hardware, an application that creates files backups cannot process cleanly, a laptop repeatedly exposed to heat or damage, or a workflow that requires twenty follow-ups to complete a five-minute maintenance action.
Our first response is to fix the problem and recommend a better operating pattern. If the pattern cannot change and the effort becomes structural, then the service model has to reflect reality.
9Do you ever recommend that a client not buy something from you?
Frequently.
If you never use helpdesk support, we will not push you into a larger support package just because we can. If a Microsoft license already contains the capability you need, we prefer using it to layering on another product. If a project can wait, we will say so. If we think you need a specialist outside our lane, we will tell you that too.
Technology counsel is more useful when the advice is not secretly a quota.
III.Security without the theater
10How candid are you about security?
Very. Security marketing is full of words like 'protected,' 'secure' and 'zero trust' that can make an imperfect system sound absolute. We prefer the less comforting but more useful version: controls reduce risk; they do not abolish it.
That is why we use layers—identity controls, MFA, endpoint protection, email security, monitoring, logging, backup separation and human verification—and why we still recommend cyber insurance.
- A password plus SMS is better than a password alone, but authenticator-based MFA or modern passwordless methods are stronger.
- A consumer VPN does not automatically make Microsoft 365 safer and can sometimes undermine location-based security controls.
- An administrator can technically see a great deal. That is why separate credentials, policy, training and audit logging matter.
- Microsoft, vendors and security products can fail. Recovery paths matter as much as preventive controls.
If there is a meaningful caveat, we'd rather tell you before you ask.
11How much access do your engineers really have?
Enough to administer the environment—which means the access is meaningful.
Our monitoring and management tools run continuously while the device is powered on and connected. Remote administration can occur without a user clicking an approval prompt because unattended maintenance and emergency response sometimes require that capability. Sessions and administrative activity are logged, and engineers use their own administrative credentials rather than impersonating the user's login.
We do not casually browse client data. But support occasionally requires seeing it: opening a restored file to prove it works, inspecting storage usage with the client, repairing a damaged document, or troubleshooting why something will not print. We minimize exposure and involve the user when the task calls for it.
12How do you know the backups actually work?
We restore them.
A green checkmark from backup software proves that the backup job believes it succeeded. It does not prove that the file can be recovered and opened. Our managed backup process includes routine test restores of sample files and email.
- In one real recovery, a cloud-only client lost roughly 100-200 GB of SharePoint data during a move. The recycle bin could not recover it.
- During restoration we discovered an API/configuration issue, corrected it in under an hour, then restored the data in roughly six hours.
- We validated the recovered data and had the client validate it too.
- That experience is why our definition of backup includes the word restore.
A backup you have never restored is still a hypothesis.
13What happens if everyone gets locked out?
We plan for that possibility rather than pretending identity systems never fail.
A normal Microsoft 365 design includes separate administrative identities, a client-controlled administrative path and an emergency/control account. We monitor privileged sign-ins. Domain ownership is also part of the recovery story because it can help prove tenant ownership to Microsoft if normal administrative access is lost.
We have lived through a Microsoft authentication-platform failure that required exactly this kind of recovery. It was slow and unpleasant—which is precisely why the recovery path exists.
IV.Cyber events: from annoying to catastrophic
A 'cyber event' is not one thing. The same phrase can describe a compromised mailbox fixed before lunch or a business-disrupting incident that consumes outside forensics, attorneys, insurers and weeks of recovery.
14What kinds of cyber incidents have you actually handled?
The range is broad, and that matters because the operating response should be proportional to the event.
- Routine account or endpoint compromise — a hijacked Microsoft 365 account or a user tricked into installing rogue remote-control software. Many of these can be investigated and remediated in well under three hours.
- Wire fraud / business-email compromise — typically more investigative. In one case an attacker compromised a participant in a development transaction, learned the real conversation, created look-alike domains and ran parallel email threads. About $1 million was sent; the bank recovered roughly $750,000 before final transfer, leaving about $250,000 of residual loss downstream.
- Sensitive-data investigation — in one incident a bad actor gained access to a workstation that contained a plain-text spreadsheet with bank-account and Social Security information for 500+ employees. The question was not merely 'was the machine compromised?' but 'can we determine whether this specific file was accessed?' That evidence-gathering effort cost roughly $5,000.
- Full ransomware recovery — in a severe case, servers and data were encrypted and approximately 40 workstations had to be rebuilt. The organization was materially disrupted for more than ten business days. Total remediation was about $500,000; our portion was roughly $150,000. The surviving immutable backup chain allowed the data to be recovered, although pulling it back from cloud storage alone took about 40 hours.
The lesson is not that every incident becomes a catastrophe. The lesson is that you cannot price, staff or govern the two-hour event as though it were the half-million-dollar event.
15Why are major cyber events outside the normal fixed monthly fee?
Because extraordinary events are economically and operationally different from routine prevention and maintenance.
The recurring service pays us to reduce the likelihood and impact of a catastrophe: patching, hardening, monitoring, backups, test restores, identity protection, alert response and preparation. If a declared event occurs, the work may suddenly involve around-the-clock recovery, evidence preservation, insurer requirements, forensics, legal coordination, mass workstation rebuilds or large-scale data restoration.
Cyber insurance exists partly to absorb that financial shock. When an incident reaches claim level, the insurer's incident-response team typically leads; we support them with system knowledge, access, documentation and recovery work.
The monthly fee pays for preparedness. Insurance helps fund the extraordinary event.
16What is your view of wire-fraud protection?
Technical controls help, but the strongest control for a high-risk financial instruction is still a second human channel.
We configure email-authentication controls such as SPF, DKIM and DMARC and use anti-phishing, identity monitoring and message tracing. But display names can be impersonated, a supplier's mailbox can be compromised, and an attacker who has read a real conversation can sound frighteningly legitimate.
For material wire instructions, use a known phone number or another established verification path. Do not verify the changed bank account by replying to the same email that asked you to change it.
V.AI, automation, and the new edge of IT
17Do you treat AI as just another Microsoft feature?
No.
AI is becoming part of the technology operating environment, but choosing an AI platform should be an architecture decision—not a reflex to enable whatever happens to come with the productivity suite.
- We compare cloud assistants, coding tools, APIs and local/open-weight models according to the work being done.
- We have built local retrieval-augmented generation (RAG) systems rather than assuming all useful business knowledge should be sent to a generic public assistant.
- We build custom applications when the workflow deserves one instead of forcing every problem into chat.
- We consider data ownership, governance, repeatability, supportability and whether the AI output can be trusted in the specific business context.
Good technology should preserve human intent, not replace a simple control with an opaque interpretation of that control.
18What makes your AI work different from simply deploying Copilot?
We start with the business process and the information boundary.
Sometimes the correct answer is a commercial cloud assistant. Sometimes it is a governed workflow around Claude or another model. Sometimes it is local RAG, a custom application, or no AI at all. We want the technology to earn its place by improving the work, not by creating a new layer of ambiguity that everyone now has to manage.
- Understand the work before automating it.
- Capture the human judgment that matters.
- Architect the data and security boundary.
- Prototype before pretending something is production.
- Measure whether the system actually improves the work.
VI.The relationship
19What does the monthly service really buy if nothing is broken?
Ideally, quite a lot of work you never have to notice, but for us it can rise to double or more than the factored hours due to circumstances you cannot be responsible for (i.e. failures in backup tools, patching, firmware, etc.)
The quiet month is not the month in which nothing happened. It is often the month in which patches applied, backups were checked, test restores succeeded, security controls were reviewed, Microsoft changed something and we adjusted for it, agents stayed healthy, licenses and domains remained current, and no one had to interrupt your business to think about any of it.
- M365 and identity-security review
- Endpoint, security-agent and monitoring health
- Patching and routine maintenance
- Backup review and restore testing
- Domain and license oversight
- Initial security-alert investigation
- Documentation and environmental knowledge
- Technology counsel when a decision appears
- Coordinating with your internal team so they can provide the best outcomes
20What happens if we outgrow you, sell the company or simply want to leave?
Then we help you leave cleanly.
You should already own the important accounts, domains and administrative credentials. We coordinate with the incoming provider, remove our tools and access, transfer what can be transferred, provide the necessary documentation and help prevent the transition itself from becoming a security problem.
Offboarding is real engineering work and is normally billable. What we do not do is manufacture dependency so that leaving becomes impossible.
A healthy technology relationship should survive the possibility that it may someday end.
21So what are you actually asking us to trust you with?
Judgment.
The tools will change. Vendors will change. Microsoft will change. AI will change. Some standards we use today will eventually be replaced by better ones.
What should remain stable is the discipline behind the decisions: understand the problem, make ownership explicit, test what matters, tell the truth about limitations, protect the ability to recover, and keep the commercial relationship fair enough that both sides can still like each other years later.
We want clients to remain in control of their business, while giving us enough authority to keep the technology healthy, secure and recoverable.
Good technology stewardship depends on clear ownership, clear boundaries, tested controls, sound judgment and candid communication.
Understand first. Architect second. Engineer third.
MSP IT Partners | Verity Technology Corporation. This document is descriptive, not contractual. Client-specific Statements of Work, pricing schedules and signed service agreements govern.
