A structural engineer wouldn’t sign off on a design without checking the assumptions underneath it. Yet most A&E firm owners run their entire practice on a technology setup nobody has examined since it was installed — accepting on faith that the backups work, the security holds, and the slowness everyone complains about is simply how the software behaves.
That’s an odd inconsistency for a profession built on verification.
What follows isn’t a checklist to tick through. It’s a set of questions worth actually asking, along with an explanation of why each one reveals something, and what a satisfactory answer sounds like. Some will produce immediate clear responses. The ones that produce hesitation are where the value is.
Start with the question nobody asks
Before the technical questions, there’s a broader one that frames everything else.
Who is responsible for noticing when something is wrong?
Not who fixes things when they break — that’s usually clear. Who notices? Who would know that a backup started failing in April, or that patch compliance has been sliding since January, or that a drive is reporting errors that haven’t caused a visible problem yet?
For a great many firms, the honest answer is nobody. Problems surface when staff complain, which means every issue reaches the people doing billable work before it reaches anyone technical.
This isn’t a criticism of whoever handles your IT. Break-fix support is genuinely capable at what it covers. But you can’t call someone about a problem you don’t know you have, and that structural gap explains most of what follows.
Questions about performance
“How long does it take to open a large model, and has anyone measured it?”
The answer you want is a number, in seconds, measured recently. What you’ll usually get is an impression.
Without measurement, nobody can say whether performance has degraded, by how much, or where the delay originates. That matters enormously, because the expensive fix is frequently the wrong one. Firms replace workstations and see modest improvement, because the constraint was storage all along — the new machines wait exactly as long as the old ones did.
A related question that costs nothing: has anyone compared the same operation at 8am and at 11:45am? If the second is dramatically slower, the bottleneck is shared, and individual hardware upgrades won’t touch it. If they’re broadly similar, the workstation or the model itself may genuinely be the limit.
“Are we adding storage capacity when the actual problem is storage speed?”
These get conflated constantly, and the difference costs real money.
Capacity is how much fits. Speed is how quickly the storage responds when several people access it simultaneously — which is exactly what happens with shared models and central files. A drive that’s half empty and slow under concurrent load will throttle everyone, and adding space changes nothing.
If your provider’s answer to slowness has been “we’ll add more storage,” it’s worth asking specifically which of the two problems they were solving.
“Are our workstations specified by role, or did we buy the same machine for everyone?”
Someone doing detailed modelling and rendering has genuinely different requirements from someone working in documentation or contract administration. Uniform purchasing overspends at one end and creates bottlenecks at the other.
This is a small point with a surprisingly large cumulative effect over a refresh cycle.
Questions about recovery
“When did we last restore from backup — what was the date?”
Note the phrasing carefully. Not whether backups run. When a restore was last performed.
The distinction is the whole subject. A backup job reporting success confirms one thing: the job ran. Corrupted data backs up perfectly well, and we have tested backups running cleanly for years that failed completely on restore.
A good answer is a date within the last three months, ideally accompanied by a written result. “They run nightly and the logs are green” is not an answer to the question asked.
“Could ransomware on our network reach our backups?”
If the response involves the server room, you have your answer.
Modern ransomware specifically hunts for connected backup storage, because attackers know a firm that can restore doesn’t negotiate. A backup drive reachable from any infected workstation gets encrypted alongside everything else — and firms discover this on the morning it matters most.
At least one copy needs to live somewhere your office network cannot reach. Our backup and disaster recovery approach is built around exactly this principle, with verification running daily rather than being assumed.
“How far back can we recover?”
This one catches people out, and the reasoning is worth understanding.
Attackers frequently sit inside a network for weeks before triggering encryption. If your only clean copy is from last night, it may already contain their tools. Firms restore successfully, resume work, and get encrypted again ten days later from the infection they carefully restored.
Multiple recovery points spanning several weeks is what allows you to go back past the date a problem began.
Questions about security
“Is MFA enforced on every account, including principals?”
The word doing the work is enforced. Available isn’t the same thing. Enabled for most people isn’t either.
Stolen credentials remain the most common way anyone gets into a firm, and Multi-Factor Authentication stops the substantial majority of those attempts. The failure mode is almost never total absence — it’s partial coverage, with two or three senior people exempted because they found it disruptive.
Those are the accounts with the broadest access and the most authority attached to their messages. Attackers look specifically for the exceptions, and finding them is rarely difficult.
Ask whether a report can be produced showing coverage. If the answer is “I believe so,” that’s a finding.
“How do consultants send and receive project files?”
Most firms have never thought about this as a security question, but it usually is one.
Large models don’t fit in email, so people improvise — personal Dropbox accounts, free transfer services, USB drives handed over at site meetings. Each of these moves project data outside any control the firm has, produces no record of what was shared with whom, and frequently leaves access sitting in someone’s personal account long after the project closed.
There’s a practical benefit to solving it too. A proper arrangement is faster than the improvisation it replaces, which is usually what persuades people to actually adopt it.
“What are we actually protecting, and from whom?”
Worth thinking through concretely rather than abstractly.
A&E firms in Sacramento work regularly with state agencies, public institutions, healthcare organisations, and educational facilities. Project files for that work often contain detailed information about how buildings are constructed, secured, and accessed — security system layouts, server room locations, structural details.
That information has value to someone whose interest is the building rather than your firm. It’s a category of exposure most practices have never considered, and it’s specific to this profession.
Questions about support
“If someone can’t work at 3pm on a deadline day, how quickly do we get help?”
The technical problem might take ten minutes to resolve. If getting to those ten minutes means leaving a message and waiting for a callback, the cost isn’t ten minutes — it’s however long it stayed unresolved.
A good answer includes a response target and, ideally, actual figures from last quarter. A provider measuring their own response times will have the number available. One that doesn’t measure will explain why measurement is difficult.
“What’s included in what we pay, and what gets billed separately?”
Ask specifically about after-hours work, onsite visits, project work, and onboarding new staff. The value of predictable costs disappears entirely if the predictable portion covers only routine tickets.
The questions clients are starting to ask you
There’s a category worth mentioning that didn’t exist a few years ago.
Public sector clients and larger private organisations increasingly send security questionnaires to their design consultants — sometimes as part of procurement rather than as an afterthought. They ask about MFA, backup testing, monitoring, and incident response, and they expect specific answers.
A firm that can respond with dates, percentages, and documentation is in a different position from one offering general reassurance. Firms that can’t answer aren’t told they lost on security grounds. They simply aren’t shortlisted, and never learn why.
That shifts the calculation. Technology investment used to be purely defensive. For A&E firms competing for institutional work, it’s now partly commercial.
Reading your results
Work through the questions above and count how many produced a specific, confident answer.
If most of them did, your firm is in reasonable shape — it’s worth confirming that the evidence exists in writing, since that’s what a client questionnaire or an insurance application will ask for.
If several produced hesitation, you’re in the same position as most growing practices. That’s not alarming, and it doesn’t reflect badly on anyone. It’s what happens when a firm grows faster than the infrastructure supporting it, which is what growth looks like from the inside.
If almost none produced clear answers, the firm is running on assumptions. Also common. Also fixable, and generally faster and cheaper than owners expect.
Where the effort goes furthest
Not every gap deserves equal urgency. If several answers were vague, this is a sensible order:
First, MFA everywhere. Cheapest, quickest, prevents the largest share of incidents. Usually an afternoon’s work.
Second, verify the backup. A real restore test tells you whether your worst-day plan is a plan or a hope. The result is either reassuring or extremely useful.
Third, get monitoring in place. This is what converts invisible problems into early warnings, and it’s the structural difference between reactive and managed IT.
Fourth, measure performance properly. Before spending anything on hardware, know which constraint is actually binding.
Everything else follows more easily once those four are settled. Our cybersecurity services cover the first, and the rest fall out of an arrangement designed around continuous oversight rather than scheduled repair.
One last thought
Engineering and architecture are professions built on checking assumptions before relying on them. The technology underneath the practice deserves the same treatment — and it’s rarely received it, mostly because nobody’s job description included asking.
The questions above take about twenty minutes to work through. The answers will tell you more about your firm’s actual position than any proposal will.
Visit our office in Valley Springs, or arrange for us to come to you — we work with A&E practices across the Sacramento region and are happy to walk through these questions properly, with measurements rather than opinions, and give you written answers to each one. Call 209-920-4077 or book a time that fits around your project deadlines.
