
Why this report exists
Most engineering firms in San Diego run a remarkable amount of high-value, schedule-sensitive work on a surprisingly small IT footprint: a Microsoft 365 tenant, a few file libraries, CAD and GIS software, a VPN, and a handful of finance workflows. When that footprint is managed reactively — fixed only when something visibly breaks — invisible problems pile up. They tend to surface at the worst possible moments: the day before a submittal, on bid day, during a client audit, or when a wire payment goes to the wrong account.
This report walks through ten of the most common, most expensive, and most overlooked of those problems. We picked them because they share three traits:
- They're common in firms running CAD, BIM, GIS, and Microsoft 365.
- They're expensive — most cost five, six, or seven figures when they hit.
- They're invisible until something breaks — which means most break/fix IT shops never proactively address them.
Two themes specific to San Diego show up throughout: the defense economy, which means many engineering firms touch projects with cybersecurity requirements (even as subcontractors); and California's breach notification law, which sets some of the strictest disclosure deadlines in the country. We've called those out where they matter.
By the end, you'll have a checklist you can run against your own environment this week, and a short list of specific questions you can ask whoever currently supports your IT.
How to read this report
For every problem you'll see:
- What it looks like in the wild
- Why it happens
- What it costs (with the math)
- Fix it — a short, ordered action list
- Ask your current IT provider — specific questions you can take into your next IT meeting. If your current provider can't answer them, that tells you something worth knowing.
Problem 1: Your file paths are getting too long, and CAD references are quietly breaking
What it looks like
A senior drafter opens a sheet to plot a submittal package and sees the dreaded "missing reference" warning. The Xref was there yesterday. It's there now if a different person opens it. The file name didn't change. After 45 minutes of CAD triage, someone discovers the project folder has crept three subfolders deeper than it was last month and the full path is now 412 characters long.
Microsoft enforces a hard limit of 400 characters on the full decoded path of any file in SharePoint or OneDrive. Cross that line and files become inconsistently accessible. Autodesk Desktop Connector (the bridge between Autodesk Construction Cloud and Windows) has its own path constraints layered on top. The result is a failure mode that looks like random user error but is actually structural.
Why it happens
Engineering firms naturally build deep folder trees: client → project → phase → discipline → vendor → deliverable → revision → archive. Add a long client name, a verbose project number, and a 50-character file name, and you're already past 300 characters before anyone notices. There's no automated scan watching for it.
What it costs
Productivity drag: 8–20 technical staff losing 30–90 minutes per week chasing broken references and resync conflicts, at $140–$260/hour billable value, comes to $29,000 to $405,000 per year.
One bad submittal: A failed packaging cycle on submittal day — rush labor, PM overhead, missed deadline — costs $10,000 to $225,000 per event. And that's before any liquidated damages.
Fix it
- Define a folder architecture standard with maximum depth, maximum folder name length, and standardized short codes for clients, projects, and phases. Get it on one page and circulate it.
- Run an automated scan of your SharePoint libraries today. Flag any path over 360 characters as a warning, and any over 400 as a hard fail. You'll be surprised how many you find.
- Move old archives off the active project libraries into a separate, shallow-root "Cold Archive" site. Stop letting yesterday's projects break today's deliverables.
- Add a preflight check at submittal time. Before a package goes out, run a script that confirms every Xref, link, and reference resolves cleanly from a controlled packaging path.
Ask your current IT provider
- Do you know how many files in our SharePoint are within 40 characters of the path-length limit?
- Do we have a written folder architecture standard for new projects?
- What's our process for catching broken Xref references *before* a submittal goes out?
Problem 2: Your SharePoint permissions are quietly out of control
What it looks like
A new hire can't open the project folder they were told to work in. Someone clicks "Request access," and the request sits in an admin's inbox for six hours. Meanwhile, on a totally different project, a former subconsultant whose contract ended in April still has read access to the engineering deliverables folder. Nobody knows because nobody has audited it.
Microsoft warns that SharePoint sites should keep the count of items with unique permissions below 5,000 per library. Most firms don't know what their count is. We've seen libraries with 30,000+. Once you cross the threshold, permission changes get slow, broken, and inconsistent — and the easy "fix" is always to grant broader access than you should.
Why it happens
SharePoint makes it easy to right-click a folder and grant one person access "just this once." Multiply that by 200 projects and three years and you have a permission mess nobody can untangle. There's no review cadence, no group-based template, and no scheduled clean-up.
What it costs
Access friction: 30 staff losing 10–30 minutes per week to access issues and workarounds = $36,000 to $203,000 per year in lost billable time.
Security drift: Harder to price, but bid leakage, IP exposure, and "wait, why does that ex-consultant still have access?" moments are real and ugly when they happen.
Fix it
- Run a baseline report. Pull the count of unique-permission objects per library. Sort descending. Your top 10 are your problem.
- Replace one-off permissions with security groups. Create three or four standard groups per project: "Internal Team," "Client Read-Only," "Subconsultant Drop Zone," "Project Manager." Apply at the folder level, not the file level.
- Make permission changes a controlled process. New unique permissions require approval from document control or IT. No exceptions.
- Run a monthly access review. Project managers attest, in writing, who currently has external access to their projects. Auto-deprovision based on contract end dates.
Ask your current IT provider
- How many unique-permission objects are in our largest SharePoint libraries right now?
- How many external users have access to our projects, and when did they each last log in?
- Do you run an access review, and how often?
Problem 3: Your CAD team is fighting their tools because the network was never designed for them
What it looks like
A drafter complains that AutoCAD takes three minutes to open a 40 MB drawing. A BIM modeler says Revit froze again when they tried to sync. The remote-office team says they "just don't use the central model anymore" because it's faster to email files around. Your IT support says the workstations are fine, the network is fine, and they can't reproduce the problem.
Here's what's happening: file-based CAD and BIM workflows were designed for local office networks. When you stretch them across a VPN, a wide-area link to a remote office, or — worst of all — a OneDrive or Dropbox sync folder, you're operating outside the supported design. Performance collapses. Sync errors creep in. Occasionally a file corrupts and someone has to restore from backup, losing a half-day of work for the entire team.
Why it happens
Remote work normalized "just put it on the VPN." Cloud sync folders are easy to set up. CAD models and central files keep growing. Nobody is monitoring open times, sync durations, or crash rates, so nobody can prove the network is the problem.
What it costs
Chronic productivity drag: 10–25 staff losing 1–4 hours per week to slow opens, failed syncs, and recovery rituals = $72,000 to $1,170,000 per year in lost billable time.
One corruption event: A single file corruption that costs 1–4 workdays of rush coordination and rework runs $10,000 to $300,000 per event.
Fix it
- Inventory every multi-user CAD or BIM model and classify by topology: same-office LAN, multi-office, remote-heavy, consultant-heavy. The high-risk ones are everything except the first.
- Block central files in cloud sync folders at the endpoint level. OneDrive, Dropbox, SharePoint sync, Google Drive — none of these are appropriate hosts for a workshared central file.
- Move multi-office collaboration to a supported cloud worksharing service instead of stretching LAN assumptions across a VPN.
- Start measuring. Track average open time, sync duration, and crash count by project. If you can't measure it, you can't manage it — and you can't prove to leadership that the network needs an upgrade.
Ask your current IT provider
- What's our average Civil 3D or Revit open time, and is it trending up or down?
- Do you have a written policy about CAD files in cloud sync folders?
- When was the last time we lost CAD work to a corruption event, and what did it cost us?
Problem 4: Your license server is one bad clock from locking out the entire design team
What it looks like
It's Tuesday morning at 9:00. The entire engineering team launches their software at the same time. One by one, they all see the same error: "-34: Clock difference too large between client and license server system." Nobody can open AutoCAD. Nobody can open Civil 3D. Production stops cold while IT scrambles to figure out what broke. The answer, when they find it, is that the license server's clock has drifted 6 minutes out of sync.
This is FlexNet — the licensing engine behind most Autodesk, Bentley, and engineering simulation software. It's exquisitely sensitive to time drift. A few minutes is enough to lock everyone out instantly. And almost no firm proactively monitors it.
Why it happens
Nobody is watching the license server. Time sync (NTP) was set up once and never verified. The license service runs as a "set it and forget it" background process. There's no alerting on clock drift, no alerting on service down, no failover.
What it costs
Per outage: A 2–8 hour outage that locks out 20 designers at $85–$170/hour fully-loaded cost = $3,400 to $27,200 per incident. If the outage hits on a deadline day, double or triple it.
Worst case: A full day of license-server downtime during a deliverable crunch = $30,000 to $93,000+ in rush labor, missed milestones, and PM overhead.
Fix it
- Configure proper time sync on the license server. Point it at an authoritative time source (your domain controller or a public NTP server). Verify it.
- Alert on clock drift. Warning at 60 seconds offset, critical at 5 minutes. This is a $0 fix that prevents a $30,000 outage.
- Alert on service down. If the FlexNet service stops, someone should know within five minutes — not when the team starts complaining.
- Document a restart runbook. Ports, daemons, log locations, restart sequence. So when something does go wrong at 4:50 PM, the response takes 10 minutes instead of 90.
- Test a planned restart quarterly. Backups you've never restored aren't backups. Restart procedures you've never run aren't procedures.
Ask your current IT provider
- Are you monitoring our license server's clock and service status?
- If our FlexNet service stopped right now, how long until you'd know?
- Do we have a documented license server restart procedure?
Problem 5: Your VPN and firewalls are months behind on patches, and that's how ransomware gets in
What it looks like
You read in the news that another mid-sized firm somewhere got hit with ransomware and was down for 11 days. You ask your IT support if you're patched against the same vulnerability. The answer is some version of "we're checking" or "we'll get to it during the next maintenance window" — which keeps getting pushed because nobody wants to schedule downtime.
The 2025 Verizon Data Breach Investigations Report (DBIR) found that edge devices and VPNs were a major share of exploitation activity, and that the median time to fully remediate exposed vulnerabilities was about 32 days — with only about half of organizations getting fully patched within a year. Attackers know this. They scan the internet daily for unpatched VPN appliances and walk in.
Why it happens
Patching feels risky ("we can't take downtime"), so it gets deferred. There's no inventory of internet-facing devices. Remote Desktop is exposed because someone needed it for a project last year and nobody turned it off. There's no patch SLA, so urgency is whatever the loudest voice in the room makes it.
What it costs
A single perimeter compromise that leads to ransomware can plausibly cost $50,000 to $750,000+ in ransom, downtime, recovery labor, lost billings, and contractual friction. Small and mid-sized firms are disproportionately the target — the DBIR notes that 88% of small and mid-sized business breaches in their dataset involved ransomware.
Fix it
- Inventory everything internet-facing. VPN portals, firewalls, management interfaces, Remote Desktop, anything with a public IP. You can't patch what you don't know about.
- Kill exposed Remote Desktop today. It is one of the most common ransomware entry points and there is no good reason to expose it directly to the internet.
- Set patch SLAs with teeth. Critical-and-actively-exploited vulnerabilities patched within 72 hours. Other criticals within 7 days. Highs within 14. Track misses.
- Require MFA on every remote access path. No exceptions, no "just for this contractor."
- Run weekly external vulnerability scans. If the scan flags something, the patch SLA clock starts ticking immediately.
Ask your current IT provider
- Can you give me a current list of every internet-facing device on our network?
- What's our patch SLA, and when was the last time we missed it?
- Is Remote Desktop exposed anywhere in our environment? Are you sure?
Problem 6: Your "backups" won't actually save you from ransomware
What it looks like
You've always been told you have backups. There's a NAS in the server room that the backup software writes to every night. Then ransomware hits, and the attackers — who have been quietly inside your network for two weeks — encrypt the NAS along with everything else, because the backup account had full network access. The "backups" are now also encrypted. You discover this on the worst day of your career.
The hard truth: a backup that lives on the same network as your production data, accessible by the same credentials, is not a ransomware backup. CISA — the federal cybersecurity agency — explicitly recommends that backups be maintained offline, because most ransomware variants will hunt for and destroy any backup they can reach.
Why it happens
"We have backups" feels reassuring. Most firms never test a real restore. Cloud sync (OneDrive, Dropbox) gets confused with backup. SaaS data — Microsoft 365, SharePoint, Teams — is rarely backed up at all because people assume Microsoft handles it. (Microsoft does not, beyond very limited retention windows.)
What it costs
A ransomware event without working backups: 3–10 business days of operational disruption at engineering firm scale = $100,000 to $1,500,000 in revenue delay, recovery labor, and contractual fallout. The DBIR's median ransomware payment is around $115,000, and that's *before* downtime, recovery, and lost billings.
Fix it
- Classify what actually matters: project files, CAD standards libraries, finance data, identity configurations. These are your "must-restore-fast" tier.
- Implement a true offline backup. Air-gapped, immutable, or both. The backup admin account should not be reusable as a domain admin account.
- Back up your Microsoft 365 data separately. Email, SharePoint, Teams, OneDrive. There are dedicated SaaS backup tools for this — Microsoft's built-in retention is not a backup.
- Test restores monthly. One file. One folder. Quarterly: one full system. Document the time it took. If you've never actually performed a restore, you don't have backups — you have hope.
- Track RPO and RTO by system class. How much data could you lose? How long until you're back up? If leadership doesn't know the answers, the answers are probably not what you'd want them to be.
Ask your current IT provider
- When was the last time we successfully restored a file from backup, end-to-end? Show me the evidence.
- If our entire file server was encrypted by ransomware tonight, how long until we're back up?
- Are our Microsoft 365, Teams, and SharePoint contents backed up separately from Microsoft's defaults?
Problem 7: Your Microsoft 365 audit logs are off, and you don't know who did what
What it looks like
Something goes wrong. A sensitive document was downloaded by someone who shouldn't have had access. Or a former employee deleted a folder on their way out. Or a client demands a record of who saw what, and when. You ask IT to pull the audit log. IT discovers that auditing was never turned on — and even if it had been, the logs only went back 90 days, and the event happened in March.
Microsoft 365 has a powerful audit log. But for small and mid-sized business licenses, auditing is not turned on by default — it has to be enabled manually. And even when it's on, the default retention is 180 days unless you license and configure longer retention. This is one of the most consequential configuration gaps in the SMB Microsoft 365 world, and almost nobody knows about it.
Why it happens
Audit logging is invisible until you need it. Nobody complains about its absence. Reactive IT support never thinks to verify it. It's a textbook unknown-unknown.
What it costs
Investigation cost blowups. Without logs, an incident response that should take 8 hours takes 80, and you still don't have answers. At $150/hour for incident response, that's the difference between a $1,200 problem and a $12,000 problem.
Contractual and legal exposure. When a client asks "show me who accessed this," and you can't, you've damaged the relationship and possibly your position in any subsequent dispute.
Fix it
- Verify auditing is on, today. Have someone log into Microsoft Purview and confirm. Document the screenshot.
- Set retention to your business reality. One year is a sensible minimum for engineering firms. Longer if you have clients who require it.
- Create saved searches for high-value events: mass downloads, external sharing changes, admin role changes, unusual sign-in locations. You want these as one-click investigations, not 4-hour scavenger hunts.
- Minimize Global Administrator accounts. Microsoft's own guidance is to keep these to a handful of named, MFA-protected, separately-credentialed accounts. Most SMB tenants have far too many.
Ask your current IT provider
- Is Microsoft 365 audit logging enabled in our tenant? Can you show me?
- How far back do our audit logs actually go?
- How many Global Administrators do we currently have, and who are they?
Problem 8: California's breach notification clock starts the moment you discover an incident — and you probably can't meet it
What it looks like
On a Wednesday afternoon you discover a former employee may have walked out with a folder of client contact information. Or a phishing attack succeeded against a project manager's mailbox. Or a vendor reports they were breached and your data may have been involved. You bring in a lawyer. The lawyer asks two questions: *what personal information was involved, and how many California residents are affected?* You don't know. You can't answer for two weeks. By then, half your statutory clock has already burned.
California Civil Code §1798.82 requires breach disclosure within 30 days of discovery, with limited exceptions. If you're notifying more than 500 California residents, you also have to submit a sample notice to the California Attorney General within 15 days of notifying the affected consumers. Engineering firms hold more personal information than they realize: HR and benefits records, client contact lists, vendor banking data, and project files that often include personal information about property owners or affected residents.
Why it happens
Meeting a statutory deadline requires three things most reactive IT environments don't have: an incident response runbook, fast access to audit logs (see Problem 7), and a basic data map showing where personal information lives. Without those, you're guessing under pressure on a clock you can't pause.
What it costs
Direct costs of a real breach response (legal counsel, notification mailings, support lines, identity-protection services for affected individuals) typically run into six figures even for a moderate event.
Indirect costs of missing the deadline can be severe: regulatory exposure, loss of client trust, and contractual penalty clauses. Even just running the response itself consumes 200–800 staff-hours of leadership, IT, and PM time = $17,000 to $136,000 in pure internal cost.
Fix it
- Build a one-page incident response playbook with three milestones: 72-hour internal triage, 7-day scoping complete, 30-day notification deadline. Name the decision owners now, not in the middle of a crisis.
- Maintain a basic data map. Where does HR data live? Client PII? Vendor banking? Three pages, kept current. This is the document that lets your lawyer answer "how many California residents?" in hours instead of weeks.
- Make sure audit logs are on and retained for at least a year (see Problem 7). You cannot scope a breach you can't investigate.
- Run a tabletop exercise twice a year. One ransomware scenario, one BEC scenario. Time how long it takes you to answer the lawyer's questions. The first time will be ugly. That's the point.
Ask your current IT provider
- Do we have a written incident response plan? Can I see it?
- If we discovered a data breach this morning, how quickly could we scope which personal information was involved?
- Have we ever run a tabletop exercise?
Problem 9: Your AP team is one fake email from a six-figure wire fraud
What it looks like
An email arrives that looks exactly like one from a regular subconsultant. "Hi, we changed banks — please update our ACH info for next month's payment." The signature is right. The thread looks real. AP updates the vendor master and releases the next payment. Two weeks later the actual subconsultant calls asking where the money is. The bank can't help. The money is gone.
This is Business Email Compromise (BEC). The FBI's Internet Crime Complaint Center reported over $6.3 billion in BEC-related transfers in 2024 alone, with a median per-incident loss around $50,000. Engineering firms are particularly vulnerable: payment amounts are large, project schedules create urgency, and vendor relationships span hundreds of companies.
Why it happens
- DMARC, the email authentication standard that prevents attackers from spoofing your domain, isn't enforced. (It exists but it's set to "monitor only" forever and never actually enforced.)
- Vendor bank changes are accepted via email without phone verification.
- The same person can update vendor banking *and* release payment. There's no separation of duties.
What it costs
Per successful event: $25,000 to $500,000+ in direct losses, depending on payment size and timing. Median around $50,000. The largest losses tend to come from intercepted progress payments on big contracts.
Indirect costs: subcontractor disruption, legal recovery efforts (usually fruitless), insurance disputes, reputation damage with key trade partners. And the slow-motion horror of explaining to your board what happened.
Fix it
- Freeze bank changes. No bank detail change goes through unless it's verified by an out-of-band callback to a phone number you already had on file — never a number from the email itself. This single rule, enforced consistently, would stop the majority of these attacks.
- Require dual approval on every bank change, and on the first payment after a change. The person who requests can't be the person who verifies who can't be the person who releases.
- Deploy DMARC properly. Most firms have DMARC at "monitor only" forever. Move it to "quarantine," then to "reject." Without this, attackers can send email that *truly looks like* it came from your CFO or president.
- Train AP and project managers to recognize the pattern. Urgent. Bank change. After hours. From an executive. These four signals together = stop and verify.
- Run a tabletop quarterly. Simulate a BEC attempt. See what happens. Fix what breaks.
Ask your current IT provider
- Is DMARC on our domain set to "reject," "quarantine," or "none"?
- Can someone outside our company successfully spoof an email from our president right now?
- Do you monitor for unusual email forwarding rules on AP and executive mailboxes? (This is how attackers stay hidden once they're in.)
Problem 10: Personal devices are accessing your business data with no controls
What it looks like
A senior engineer checks email on their personal phone in line at the coffee shop. Their kid borrows the same phone to watch YouTube. The kid taps a sketchy link, the phone gets compromised, and now there's an attacker sitting on a device that has access to your Microsoft 365 tenant. Your IT team has no idea. There's no MDM enrolled. There's no compliance check. There's no way to remote-wipe the device because it isn't enrolled in anything.
Or simpler version: a project manager leaves the firm. They had email on their personal laptop. Six months later you discover they still have it.
The 2025 DBIR found that a substantial share of compromised business systems were on non-managed devices that hosted both personal and corporate credentials. This is one of the easiest gaps for attackers to exploit, and one of the hardest for reactive IT to even see.
Why it happens
Allowing BYOD ("Bring Your Own Device") is easy. Governing it is hard. There's no Conditional Access policy requiring devices to be compliant before they can connect to email or SharePoint. There's no MDM lifecycle. Credentials live on personal machines that nobody at the firm has any control over.
What it costs
Reduced breach probability is the main payoff — and breaches in this category are the ones that hurt most because they're often invisible until something dramatic happens. Plan-level exposure: $20,000 to $200,000 per year in avoidable risk and waste, plus the catastrophic-scenario tail risk of a credential-based intrusion.
Fix it
- Decide which systems require a managed device. Tier 0 is identity and admin portals. Tier 1 is email, SharePoint, project libraries. Tier 2 is general SaaS. At minimum, enforce managed-device-required on Tier 0 and Tier 1.
- Turn on Conditional Access in Microsoft 365 to require device compliance for those tiers. This is included in most Microsoft 365 Business Premium and higher licenses — many firms own it and don't use it.
- Enroll personal devices in basic MDM if they're going to access business data. Microsoft Intune (or equivalent) can do this with minimal user friction and significant security benefit.
- Have a formal offboarding checklist that revokes access from personal devices when someone leaves. Right now, most firms don't.
Ask your current IT provider
- Do we have Conditional Access turned on for our Microsoft 365 tenant?
- How many personal devices currently connect to our email and SharePoint?
- When an employee leaves, what's our process for revoking access from devices we don't own?
Bonus: Defense work and CMMC
If your firm does any work — directly or as a subconsultant — on projects that touch the U.S. Department of Defense (DoD), this section is for you. If you don't, you can skip it. (But read it anyway, because the supply chain is broader than most firms realize.)
What's happening
The DoD has finalized the Cybersecurity Maturity Model Certification (CMMC) program, which requires contractors handling Controlled Unclassified Information (CUI) and Federal Contract Information (FCI) to implement and verify a specific set of cybersecurity controls based on NIST 800-171. The program has a phased rollout schedule, and once a phase is in effect, contracts in scope can't be awarded without the required CMMC status.
San Diego's economy is heavily defense-influenced. Even firms that don't think of themselves as "defense contractors" — civil engineers doing site work for a defense client, structural engineers on a Navy facility, environmental consultants on a base remediation — are increasingly subject to CMMC requirements through prime contractors.
Why this is more urgent than it feels
CMMC readiness takes months, not weeks. You need to scope what counts as CUI in your environment, build an enclave to isolate it, document controls, gather evidence, and (depending on your level) prepare for a third-party assessment. Firms that wait until a prime contractor asks them about CMMC status have already lost the contract.
What it costs to get wrong
Revenue eligibility risk: if 10–40% of your revenue is defense-adjacent — common in San Diego engineering — losing eligibility on those contracts is a six- to seven-figure annual hit for a mid-sized firm. The cost of getting *ready* is a fraction of the cost of losing the work.
Fix it
- Start with scoping. Where does CUI live in your environment today? Email? File shares? Project portals? Most firms haven't formally answered this question.
- Choose an architecture. For most small and mid-sized engineering firms, a *segmented enclave* — a logically isolated environment for CUI — is the right answer, not a full-tenant compliance build-out.
- Map your gaps to NIST 800-171. It's 110 controls. You probably already have 30–50 of them in some form. The gap analysis tells you what's left.
- Build a phased plan aligned to the DoD's rollout timeline and your client's likely contract requirements. Track progress monthly.
Ask your current IT provider
- Have we ever done a CMMC scoping exercise?
- Do we know which of our active contracts have CMMC flow-down requirements?
- Could we pass a NIST 800-171 self-assessment today?
The big picture: where to start
Not every problem deserves equal attention. Here's how the ten stack up by priority:
Critical priority:
- VPN/firewall patch debt — High likelihood, catastrophic impact
- Backups not actually ransomware-resilient — High likelihood, catastrophic impact
- Microsoft 365 audit logging disabled — High likelihood, very hidden
- BEC payment fraud — High likelihood, catastrophic impact
- Unmanaged personal devices — High likelihood, high impact
High priority:
- California breach notification gap — Medium likelihood, high impact
- CAD over VPN/cloud sync — Medium likelihood, high impact
- SharePoint permission sprawl — High likelihood, medium impact
- File path length debt — High likelihood, medium impact
- License server time drift — Medium likelihood, high impact
A practical 90-day plan
You don't fix everything at once. Here's the order we'd suggest if we were sitting next to you.
First 30 days — stop the catastrophic stuff:
- Inventory and patch internet-facing devices; kill exposed Remote Desktop
- Verify backups are truly offline and run a test restore
- Turn on Microsoft 365 audit logging and extend retention
- Implement the bank-change verification rule for AP
Days 31–60 — close the chronic gaps:
- Roll out DMARC properly (move from "monitor" toward "reject")
- Turn on Conditional Access for Microsoft 365
- Stabilize the license server (NTP, monitoring, runbook)
- Run the first tabletop exercise
Days 61–90 — make it durable:
- SharePoint permission refactor and access review cadence
- File path scan and folder architecture standard
- CAD/BIM collaboration topology assessment
- One-page incident response plan and basic data map
- Begin CMMC scoping if defense work is in your future
What good IT support for an engineering firm actually looks like
If you've read this far, you've probably noticed a pattern. Almost none of these problems are "the printer is jammed" or "I forgot my password." They're at the intersection of IT, project operations, finance, and compliance — and most of them only get fixed when somebody is *proactively looking for them*.
A good IT partner for an engineering firm should be:
- Watching your CAD environment — open times, sync rates, license server health — not waiting for tickets
- Treating Microsoft 365 as critical infrastructure, not as a mailbox provider — auditing on, retention configured, Conditional Access enforced
- Running monthly access reviews with project managers, not letting permissions drift
- Patching your perimeter on a written SLA, not when there's "a maintenance window"
- Testing your backups, not just running them
- Working with your AP team on payment fraud controls, not just spam filtering
- Aware of California breach notification timelines and what would be required to meet them
- Helping you scope CMMC if defense work is part of your future, not telling you "we'll get to it"
Reactive IT — "call us when something breaks" — works fine until one of these problems goes off. Then it doesn't, and the cost of the one event dwarfs years of savings.
Want a focused conversation about your environment? We put this report together because we noticed how often these specific problems get missed — and how expensive that miss is. In about an hour, walking through this checklist against your actual environment, we can usually tell you which of the ten problems you currently have, roughly what they're costing you, and what it would take to fix the top three. Book a free IT assessment — no obligation.