A lot of technical programs treat security and compliance like a gate. You build the thing, hand it to the security team, and wait to find out what you did wrong. I’ve done it that way, and I’ve watched it cost weeks, sometimes months.
Over 25 years in healthcare, financial services, and government-regulated work, I’ve come to believe the opposite. Compliance is a design input, not a final checkpoint. Here are the lessons that got me there, and how you can apply them to your own programs.
Agree on what “done” means before anyone builds anything
When a program touches security, you’ll usually have several groups who each own a piece of the answer. Security wants one thing, legal wants another, and the business wants it shipped yesterday. None of them are wrong. The problem is that they often don’t find out they disagree until late in the project.
I learned this at Microsoft working on the Windows Genuine service. That system sat right where licensing, security, and customer trust meet. Seven licensing groups and three security teams all had requirements. The most valuable thing we did was get every one of those requirements written down in one place and settle the conflicts before design started.
How to apply it: In discovery, build a single definition of done that lists each stakeholder’s non-negotiables side by side. Where two requirements conflict, flag it right away and get a decision from someone with the authority to make it. It’s a lot cheaper to come to agreement about a spreadsheet than about a finished system.
Start with a security and compliance inventory
You can’t secure what you don’t know you have, and you can’t prove compliance on assets you can’t find. It sounds obvious, but I’ve seen plenty of programs start writing controls before anyone knows what’s actually on the network.
At Asurion, we built an automated asset discovery process that covered every site worldwide. It wasn’t glamorous work. It was the foundation that made everything else possible, from license compliance to patching to audit readiness.
How to apply it: Before you scope security controls, ask for a current, verified inventory of devices, applications, identities, and data stores. If one doesn’t exist, make building it the first work-stream. It’ll surface risks you’d never find otherwise.
Treat availability as a compliance requirement
The security triad is confidentiality, integrity, and availability. Most compliance conversations focus on the first two. But in financial and insurance-backed operations, downtime shows up on the balance sheet fast, and in healthcare it shows up at the bedside.
At Asurion, failures in our back-end logistics systems had real daily revenue exposure. Rebuilding those systems wasn’t labeled a security project, but it absolutely was a risk project.
How to apply it: Put a dollar figure, or a patient-impact statement, on downtime for every critical system in your program. Once that number is in front of leadership, resilience, DR/BC, and failover testing stop being “nice to have” and become requirements.
Put regulated data in your dependency map
n healthcare, HIPAA isn’t something you review at the end. Every data migration, access change, and interface cutover can touch protected health information. If that isn’t in your plan, your plan has a gap.
I learned this through hospital M&A work at Ardent Health (AHS) and at Thomas Jefferson University and Einstein Healthcare Network. We were moving imaging data, Epic workflows, and clinical applications while hospitals kept running. Every step had to answer the same questions about the data moving with it.
How to apply it: For every migration or cutover step, add three questions to the runbook. What regulated data moves in this step? Who has access to it during and after? What’s the audit trail? If you can’t answer all three, the step isn’t ready.
When regulations conflict, map them side by side
Global programs run into rules that pull in different directions. What one country requires, another restricts. You can’t solve that by reading each regulation on its own.
I worked through exactly this at Inseego, where the integration of Nokia’s Fixed Wireless Access business brought in teams across Europe, India, and China. That meant working with GDPR, India’s DPDP Act, Chinese data regulations, and U.S. export controls at the same time.
How to apply it: Build a matrix with requirements as rows and jurisdictions as columns. Where the columns conflict, that’s your decision list. Each conflict needs an owner, a proposed approach, and a sign-off from legal. That turns an overwhelming regulatory picture into a manageable set of decisions.
Make the security and compliance risk register something people actually use
How to apply it: Give every risk a named owner, not a team. Tie each one to a decision or action with a date. Review the top risks in your regular status meeting, not in a separate compliance meeting nobody attends. And write it in plain language, so an executive can read it in five minutes and know where to focus.
The common thread in security and compliance
The industries change, and so do the regulations. The approach doesn’t. Bring security and legal into discovery, not review. Know what you have. Put a cost on failure. Trace your regulated data. Map conflicts early. Keep your risk register alive.
None of this requires a bigger team or a bigger budget. It just requires treating compliance as part of the program from the start. If you’re running a program where security and compliance are on the critical path, I’d love to hear what’s worked for you.
Andrew Weinberg is a Principal Technical Program Manager with 25+ years in healthcare IT, enterprise infrastructure, SaaS, and M&A integration.
Get new field notes by email
Practical lessons on cutovers, M&A integration, and keeping high-stakes programs on track. New posts most Tuesdays.
No spam. Unsubscribe anytime.