In this post, we are discussing the early stages of company building, but through a lens of effort to implement security practices. Considering the harsh realities of operating in a pre-product-market-fit environment, we present a framework for pragmatic security initiatives. By adopting this framework, time is deliberately spent on activities that can scale, as an alternative to being reactive to security concerns from customers, auditors or incidents.
A trapeze of trade-offs
When starting a company, or building any new product, every decision is a balancing act that considers trade-offs of one kind over another. There are challenges of limited time, resources or information and a multitude of unknown factors that must be discovered. Goals are often moving targets, representing the best course of action at a particular moment in time, but certain to change over the course of months or weeks. Definitions of the business itself are vague and evolving.
These characteristics are naturally imbued in technical work as well - doing discovery about the nature of a problem is essential to solving it. Most startups are chasing the elusive "product-market fit", a term that is highly dependent on a cohesive vision for the product and market.
This highly dynamic environment isn't a liability for a young company - in fact it's a critical advantage to be able to react quickly to new information and incorporate it into a product. For this reason alone, startups are able to nimbly innovate around incumbents, who may have huge leads in capitalization or product in a category, but are unable to navigate change in the broader market quickly enough to stay relevant.
Nobody likes debt, except for the rich
Many technical teams face another trade-off in early product development - the ability to quickly ship features without taking on too much "technical debt". This kind of debt manifests itself as areas of the technology stack that will need to be refactored in the future due to scaling challenges or updated product features. These refactoring projects can represent major roadblocks to continuing product innovation or the ability to service a growing customer base, sometimes taking months to complete.
The ambition to avoid technical debt puts a lot of focus on the initial technology choices made by engineering teams - such as which programming languages, application frameworks, runtime infrastructure and data storage systems to use. Teams strive for an ideal of choosing the "right tool for the job", but also must consider team dynamics and competencies of individuals. Application runtimes and data storage design are particularly hard decisions to revisit, even with the advanced tooling available today. Changing these types of systems become lateral moves with respect to product capabilities, and end up representing significant opportunity cost.
Technical debt trade-offs also extend to what kind of security measures are put into place. Remediating security risks are directly correlated to the choice of programming language or runtime environment, for example, as each technology has vulnerabilities specific to them. The potential for change to these layers of the technology stack is then compounded by the need to change security controls built on top of them.
There is also the perception that extra "security" adds rigidity to a technical system - more "checks" become a (sometimes literal) drag to releasing changes, and limiting access to systems for direct updates has to be replaced by approvals from managers.
Unfortunately these factors encourage the consideration of security to be an afterthought for most early stage startups. A product can't be hacked if it doesn't exist yet, obviously?
Rabbit holes always go down
Complicating these trade-offs is that security is an incredibly wide and deep domain to comprehensively cover. There are seemingly endless optimizations to be made in the name of security, literally too many to even begin to list here. And with ambiguity from the lack of product definition, there are few guideposts to orient a "landing zone" where specific security measures might be more effective than others.
There is also an impact on velocity to consider, as most security controls will be perceived to "slow" some operations or tasks. Take access control as an example - in normal circumstances it's inconceivable that a company would grant access to customer data to every employee. But when the entire company is 6 employees, giving full access broadly across systems is typical. To have fine-grained role-based access controls for a few people is a waste of time to set up and maintain, and would come at the cost of other company-building activity. Yet strong access control is the cornerstone of any information security program.
The real risk comes when security practices don't evolve as the organization scales. Role-based access may not make sense for 6 people, but once there are 30 employees, it's reasonable to expect that teams, groups and hierarchy has found its place in the company. This is where reactive security can set in, as in the absence of internal security prioritization cedes to external forces mandating improvement, such as a key customer doing due diligence or the need for an external auditor attestation.
Scaling security - outline a roadmap & implement foundations
To avoid the fire drills that invariably accompany a reactive security posture, early stage startups should outline their security roadmap over a multi-year term. This has the benefit of allowing for agility in the near term while creating a framework for improving security over time. Taking access controls as an example again, a roadmap can highlight that a small number of people have broad access at the beginning, but as headcount increases there are corresponding plans to add roles-based authorization and SSO.
Other worthwhile initiatives to embrace early include - drafting an information security policy; defining roles and responsibilities for security in the organization (typically split between CEO and CTO); maintaining a list of vendors, sub-processors and SaaS tools in use; creating an employee handbook that outlines company values, etiquette and necessary trainings. There are public templates available for Privacy Policy and Terms of Service that are easy to amend with details about data being collected and how it is secured specific to the product. Drafts for these initiatives do not need to be exhaustive, and in some cases they might just be a few pages of materials, but they are establishing a precedent that can be revised over time and demonstrate to auditors a recorded history of good practices.
This "scaling security" approach should identify controls that can increase individual velocity as well as security over time.
Access control
Setting up a managed employee directory early on has a lot of benefits - it's a system of record for contact information, reduce risk of data loss, and provide an auditable record of individuals' authorization. Often it will include features like organization charts that capture the reporting structure of employees and managers.
This becomes a useful scaling tool for SSO and RBAC to be built out over time. It has a big impact as the company begins to grow by onboarding new employees into critical systems quickly. Roles can be refined in the directory as they evolve during restructuring, and this becomes a useful source of truth. At the time of this writing, a popular HR system called Rippling has built their business on the thesis that an employee directory is the critical system in every company.
Change management
Implementing a CI/CD pipeline for change control can immediately reduce engineering effort to publish updates to production environments. This can decrease the time it takes for new engineers to become product contributors to the product. It encourages healthy engineering practices by standardizing the review and execution of changes to non-local environments.
Over time this pipeline will be an integration point for all sorts of security controls - automated tests, static code scanning, infrastructure scanning, release tagging, and approval workflows to name a few.
Device management
Endpoint management or MDM can streamline IT help desk management, as well as ensure that employees are provided with the software they need from day one. This can take effort and cost to centralize early, so it's common to start with a BYOD policy and good documentation on how to operate workstations. It can be a manual control owned by managers to ensure that EDR, biometrics or other physical security controls are properly enabled.
Vendor due diligence and approval
Even a lightweight justification form can start to build organizational muscle around oversight for new vendors, and establish that tools shouldn't be adopted ad hoc by anyone. This diligence needs to mature every quarter, as it's a focal point for assessments, and ultimately culminates in an annual review of every vendor. It's key to start this practice early, and avoid scrambling to review hundreds of tools retroactively.
Data classification
Start with an outline of broad categories of data that is expected to be collected through websites, applications or by internal employees. Classifications can be as rough as Public/Private/Confidential and the locations of storing and processing data can name whole categories of tools, such as CRM or public cloud IaaS.
Leverage platforms, not tools
With upfront planning, it's helpful to identify platforms that can be minimally configured at the outset to not drag on velocity, but serve as a building block for improving both security and operations as the company grows. A lot of benefits of having a roadmap is being able to leverage existing systems to meet new security goals. In the examples above, adding scans for CVEs is very easy to insert into existing CI/CD pipelines; or enforcing MFA for every log-in by "flipping a switch" on SSO already active in a company directory.
An overlooked benefit of "scaling security" plans is that it helps to defend deficiencies in the control environment at the early stage. It's much easier to say "we publish alerts into Slack today and plan to install a SIEM solution in the next two quarters" than answer "N/A" when asked about security alerting.
Moving targets
Like product features and company goals, security priorities will shift as a company grows and the needs change. These kinds of changes are also easier to capture in a living roadmap, with justification documented for posterity.
The antithesis of having a plan is reactive security initiatives that compound over time into dysfunction. At some stage a dedicated security team gets hired, but they are so overwhelmed that they default to saying "no" to any request. This has a degrading effect overall as others in the organization actively avoid engaging with the security team on a regular basis.
Alternatively, having a vision for security, even one that is aspirational, can guide decisions and investment of effort in areas that can have an amplified impact on velocity, and pay dividends as the organization grows and scales.
Top comments (0)