Security is often viewed – incorrectly – as a necessary evil. For startups, launching a cybersecurity program can seem full of complexity, compliance, and cost. Salman Baset, in contrast, makes the compelling case that security is the foundation for successful scaling. After earning his PhD and developing his research skills at Columbia University, Salman joined IBM Research to work in the emerging space of cloud computing and cloud security, and then joined the blockchain solutions division to architect blockchain security for TradeLens and IBM Food Trust, alongside Fortune 500 partners such as Maersk and Walmart. He then moved to MongoDB to build security and compliance products before leading security and IT at HealthVerity.

The transition from research to business forced Salman to unlearn his instinct for perfection. In research, deep details matter in order for research to withstand critique and test of time. In security leadership, the question becomes: What is good enough for the business? That shift defines his approach. Security should enable growth, not prevent it. Compliance should emerge as a byproduct of solid foundations, not as the goal itself.

Salman’s message to founders challenges conventional wisdom about when to invest in security and how to build programs that scale. The companies that get security right from day one treat it as a competitive advantage. The ones that wait find themselves untangling expensive technical debt when enterprise customers come knocking.

Build security from day zero

When building a security program, founders face a strategic choice: Build compliance programs specific to each geography, requiring significant effort every time they want to expand into a new market, or build a security flywheel where foundational controls satisfy multiple compliance regimes simultaneously.

“If one is building their security program in a way so that compliance is a byproduct, a security flywheel, then one would be able to take some of the basic controls they have built and apply them in multiple places, apply them to the multiple compliance regimes,” Salman said. “That’s the goal here: To build a security program where ultimately compliance is a byproduct and to create a security flywheel.”

The foundation requires several baseline controls from day one: Separate environments for development, staging and production. Encryption at rest and in transit. Multi-factor authentication and single sign-on. Basic management of non-human identities. Common sense change management controls that are important for both security and operational excellence. These controls satisfy the broadest set of customer security requirements across geographies.

“The ultimate focus is on the customer,” Salman said. “And there are two types of customers: One that likes a product, but needs a compliance checkbox to unlock a market. And then there are customers with a broader set of security requirements that are common across multiple geographies.”

This strategy prioritizes breadth over specificity. “You want to build a security flywheel so that you are serving the broadest customer set,” Salman said. “Then, when you are 80 percent there, you start going into these specific geographies or specific compliance regimes.”

Someone once asked Salman when they should pursue FedRAMP authorization for selling to the U.S. government. “Go get at least five banks or five financial institutions or equivalent customers,” he said. “And when you have that, then you can start going into FedRAMP, because then you’ll have a good sense of customer needs from them.”

Summarize security in one sentence

In 2017, Maersk suffered a catastrophic ransomware attack that crippled all its systems. Ships could not move. Payloads were stuck. The company faced massive financial losses, and every partnership project risked shutdown. IBM was building TradeLens with Maersk at the time, a blockchain platform to digitize how shipping containers and goods move across the world.

“At that time, I was asked to put together a presentation for the Maersk senior leadership on essentially one slide, no more than that, which talks about the security of the platform,” Salman said.

He leveraged threat modeling frameworks to communicate in business terms what the threat was, what the solution was and how the platform would be impacted. The presentation went through IBM channels to senior leadership, who delivered it to Maersk executives. 

“The lesson that I drew from that episode was that it’s important to communicate security in simple terms with executives to show the value it brings,” Salman said. “It must be simple, it must be explainable and it must not be complicated so that a non-technical executive who is very sharp can get the value of it and make a go-no-go decision based on the materials presented to them.”

Security teams often overwhelm leadership with technical detail. “We in the security community tend to have this habit of giving too much information to the leaders, often without recommendations on what to do,” Salman said. “The art of summarizing the information in non-technical form along with a recommendation to leaders is important.”

Salman’s PhD training prepared him for this discipline. Every research paper includes an abstract that condenses complex findings into six or seven sentences. He often recalls Professor Alfred Aho of Columbia University, who created the AWK utility. When PhD candidates came to present as faculty candidates, Aho would make one request: Explain in one sentence what your research is about.

“You are a PhD candidate, you’re about to show off all of the stuff you’ve done, and here is somebody asking to explain everything you’ve done in one sentence,” Salman said.

“It’s not the business’s job,” he said. “It’s your job as a security leader to make the business feel comfortable and to make sure that information is presented to them in a way that will make executives feel comfortable with the recommendation being made to them.”

Secure by default beats secure by effort

Salman organizes security capabilities into three buckets: Baseline controls that represent industry standards, compliance necessities that unlock specific markets and product differentiators that reduce customer effort.

“The basic security functions I talk about, like encryption, MFA, access control, change management, patch management, they are very important to sell into an enterprise,” Salman said. The differentiators vary by product. For example, a password manager needs detailed encryption capabilities and password protection mechanisms. “In that world, that is a product differentiator,” he said.

The real opportunity lies in secure defaults. “Should one have to turn on a knob to enable TLS, to enable encryption at rest, or is the encryption at rest already enabled by default?” Salman said. “An example that comes to mind is Google Cloud versus AWS. AWS obviously had been in the cloud space for a long time. Google Cloud was a late entrant, but they made a decision to have encryption at rest by default, which could not be disabled by any of their customers.”

That decision created a competitive advantage. “That was one less thing for the security teams at a customer to check for,” Salman said. “That became a differentiator for Google: One less thing to do.”

At MongoDB, Salman emphasized a critical principle. “In cloud, there’s a concept of shared responsibility,” he said. “Shared responsibility is not equal responsibility. It does not mean the customer has the same equal responsibility as the cloud provider.”

A competitor solving the same problem in two steps instead of 20 will eventually win. “Any security feature that a product can provide that lowers the overall effort of the implementers, whether they are the security teams or whether they are the end developers, is a product differentiator from my perspective,” Salman said.

Technical debt compounds from day one

Some security mistakes prove nearly impossible to fix later. In Salman’s experience, the wrong foundational decisions will create technical debt that compounds as the company grows.

“I would break down this question into cultural aspects and technical aspects,” Salman said. “From a cultural perspective, the decision mechanisms that work for a five-person startup will be different than they work for a 25-person startup than they work for a 50-person startup, and so on and so forth.”

Cultural debt accumulates when teams cling to processes that worked at small scale. Technical debt accumulates from foundational mistakes that cannot be reversed or are very costly to reverse.

“You have to make sure that you’re building and laying the foundation correctly,” Salman said. “For example, you’re building separate environments for development, staging and production. If you’re not doing that, if you’re building everything in production, it’s basically screwed from day one. You cannot fix that later.”

The same principle applies to encryption. “Similarly, if you are not making some decisions to ensure basics like encryption at rest, encryption in transit, they can be difficult to fix later,” he said.

Maintenance represents another hidden cost that founders underestimate. “You also have to realize that as you’re building software, you have to maintain that software, and maintaining software costs effort and time,” Salman said. “Patching is not free. Security is never free.”

The comparison to physical infrastructure reveals the gap in thinking. “In buildings, you have to do maintenance,” Salman said. “And in planes, you have to do maintenance. In cars, you have to do maintenance. We have accepted maintenance as a fact of life everywhere. But when it comes to software maintenance, we don’t pay as much attention as we should. A redeploy to fix a vulnerability is still maintenance.”

The consequences vary by context. A plumbing leak floods every apartment in a building, creating catastrophic damage. A security breach at a company selling basic consumer goods may not carry the same severity. Those differences in consequences explain why software maintenance receives less emphasis than it deserves. The maintenance burden is real, regardless of consequence severity, which makes one practice critical for startups. 

“While it’s important for a startup to try multiple things, if one doesn’t work out, it’s important to shut it down,” Salman said. “Because if those things are not maintained, then they incur technical debt. They will cause issues down the road, both from a security perspective, from a cost perspective and from a maintenance perspective.”

Scale security with empathy and paved roads

Compliance programs create inevitable tension. Engineers feel frustrated by limitations and ambiguous jargon; compliance teams struggle to get their requirements met. When this friction intensifies, Salman preaches one key practice.

“Empathy,” Salman said. “It’s important to build empathy with the engineers. It’s important to build empathy with the compliance folks. Everybody’s trying to do their job.”

Engineers need to understand that compliance opens markets and the initial pain creates velocity later through the security flywheel. Compliance teams need to understand that engineers face deadlines and will be held accountable for delivery. When risks emerge that threaten timelines, surface them early and collectively decide whether to prioritize the feature or the compliance requirement.

“One of the challenges that security people often run into, we would go and tell people, ‘Go do this,’ but without explaining the reason why,” Salman said. “The way compliance people and engineers communicate about compliance can make or break the program.”

The deeper solution involves creating what Salman calls secure paved roads. “You have to realize that humans, by their nature, are lazy,” he said. “And so they are going to take a shortcut to solve a particular issue. And if the secure part is more difficult, then humans are naturally going to gravitate towards the easier part. That’s just human nature. There is nothing we can do about it. Therefore, we have to figure out a way to create a culture where the secure path is the easier path.”

Security succeeds when it becomes a team sport. Create public channels where employees are empowered to report security issues, and the security teams are seen responding to them as appropriate. Celebrate non-technical employees who identify problems.

For early-stage founders, Salman offers clear advice. “You want to have somebody who can do multiple things,” he said. “Focus on your customers. Not only what customers are telling you, but also what they are not telling you. Sometimes customers would say they want a faster horse, but what they really want is a car.”