You Didn’t Ask for It. That’s Not the Point.

Think about the last time you sat across from a doctor, an accountant, or a lawyer.

Did you hand them a checklist? Did you specify every standard they were expected to meet or every protection you were expecting them to apply? Because you are a normal human, we’ll just assume that you trusted them to do their job in the way a normal human would... Not blindly — but reasonably. Because the entire basis of that type of relationship is that the person providing the service knows things you don’t, and that their level of professional knowledge comes with an obligation to act in your interest.

Nobody tells their doctor “please wash your hands before you examine me.” The doctor just does it because it is good for his/her patient. Nobody tells their accountant “don’t share my financial records.” The accountant just protects their clients information to prevent strangers from getting it. Those things don’t get stated because they don’t need to be stated. They are so fundamental to the relationship that requiring them to be explicitly requested would be absurd.

That is what an implied requirement looks like when it works.

The question worth asking is what it looks like when it doesn’t.

When the Knowledge Gap Becomes a Shield

In technical program work, there is a defense that shows up with uncomfortable regularity. It sounds like this: “You didn’t ask for that.”

This stunning gem of professional failure is typically deployed at delivery time (a.k.a. the end of the project). When the gap between what was needed and what was built becomes impossible to ignore or hide in performance metrics. And it is technically true often enough to be very dangerous. The EXACT requirement wasn’t written down. It wasn’t in the contract. It wasn’t specified in language that could be pointed to.

What this BS argument leaves out is the reason WHY it wasn’t specified. The person who needed it didn’t have the technical knowledge to specify it in the first place. They came to a specialist. They trusted that the specialist would apply their expertise in the interest of the person they were serving, not just to the exact boundary of what was written down.

They trusted the implied requirement that you would build it the way that it should be built. Using that knowledge gap as a contractual defense is not a neutral act. It is a betrayal of the relationship that created the gap in the first place.

A doctor who says “you didn’t ask me to wash my hands” is not making a legal argument. They’re admitting they understood they had an obligation and chose not to honor it. The excuse doesn’t save them. It condemns them.

The same logic applies to all these types of situations. It just gets applied less consistently outside of medicine and law.

Security Is Where This Cuts Deepest

Of all the places implied requirements live, security is a field where the consequences of not meeting them are the most serious.

The person commissioning a system (any kind of a government program, a procurement, a contracted capability) often does not have the technical depth to specify every security control they need. That is not negligence. That is the nature of the problem. Security is complex, evolving, and deeply specialized. The entire reason you bring in experts is because you cannot navigate it alone. So, the person commissioning the work has a valid expectation of professionalism from the technical experts they hire!

When those ‘security’ experts deliver a system without encryption, without access controls, without audit logging, without the protections that any reasonable person would assume were included, they are not just defending their delivery… When they point to the requirements document and say: ‘it wasn’t specified’, they aren’t making a false claim ‘legally’ speaking... What they are doing is exposing the gap between what they were hired to do and what they chose to do.

The person who bought the house didn’t ask for locks. They assumed locks. Because a house without locks is not a house. It is a structure that fails at one of its most fundamental purposes. A system without security is the same thing. It is a capability that fails the moment it encounters the condition it was built to operate in.

And unlike a poorly specified feature that wastes budget and frustrates users, a security gap does not stay contained. It exposes data. It enables breaches. It causes harm to people who had no part in the requirements conversation and no ability to protect themselves from its outcome.

The stakes are not abstract. The knowledge gap is not theoretical. And the “you didn’t ask” defense, in a security context, is not a contractual position. It’s a confession.

What Professional Obligation Actually Means

Medicine codified this a long time ago. Informed consent. Do no harm. Finance/financial advising did too, using terms like fiduciary duty. These are not aspirational statements. They are enforceable obligations that exist precisely because the knowledge gap between specialist and client is real, significant, and consequential. And because supposed experts didn’t voluntarily meet those expectations.

They exist because the bodies who govern and regulate those fields recognized that leaving the implied requirements to chance produced outcomes that were indefensible. So, the obligations were made explicit. The professional is required to act in the client’s interest even when the client doesn’t know enough to demand it.

Technical program work, and security specifically, has not fully made that turn. Current contractual models still allow the knowledge gap to be treated as the client’s problem. If you didn’t write it down, you didn’t ask for it. If you didn’t ask for it, you don’t get it. If something goes wrong because of what wasn’t specified, that’s a requirements failure, not a delivery failure.

That model protects the wrong party.

The specialist has the knowledge. The specialist has the expertise to know what should have been in the requirements even when the client didn’t. The specialist took on the work knowing that gap existed. The obligation to close it — or at minimum to surface it explicitly rather than silently benefit from it — sits with the person who understood what was missing.

Implied requirements are not a loophole. They are a test of whether the expertise being sold is actually being applied in the interests of the person/people who needed it.

The Question That Has to Be Asked

Every program, at every stage, involves people who know more than the people they are serving. That asymmetry is not a problem. It is the point. It is why expertise was brought in.

What matters is what that asymmetry obligates.

Before delivery, someone with technical depth needs to be asking: what did this customer need that they didn’t know to ask for? What have we assumed they understood that they almost certainly didn’t? What gaps exist between what was specified and what is actually required for this thing to work safely, securely, and in the interest of the people it was built to serve?

Those questions are not scope creep. They are professional responsibility. And depending on the customers and/or products involved, could literally be a matter of life or death.

The customer hired you because the subject matter was too complex to navigate alone. They trusted that the expertise they were paying for would be applied in their interest — not just to the edges of what they were able to articulate.

The knowledge gap is the reason they hired you.

It was never meant to be a defense.

At Leitwolf, we treat implied requirements as real requirements — because the people we serve are counting on us to know what they couldn’t have known to ask for. If that’s the kind of partnership your program needs, let’s talk! Contact us: info@leitwolf.net