For many early-stage teams, the concept of security can be squishy and ambiguous. Almost everyone publishes a security page or policy, but it’s hard to know what exactly you should include. Should we spell out how we handle encryption? Do we need to do pen testing? What’s a vulnerability scan? 🤷♀️🤷♂
Introducing “management” to security means taking it from squishy and ambiguous to clear, measurable, and repeatable - all the necessary ingredients for scaling security. We can adopt frameworks and best practices, establish objectives, baselines, and metrics for our program, and clearly measure the results in terms of business impact.
Security management is the practice of systematically designing and operating business processes and systems to achieve your security and business goals. Done well, security is built into how your company runs. Just like you end up with business processes to manage software development, bookkeeping and finance, and customer support, security becomes another set of repeatable business processes. And over time you can measure how you’re doing and improve. Think of it like leveling up what Brian Kreb’s calls your security maturity level.
Ideally you end up with a security management system that acts as a source of truth for everything that was supposed to get done and everything that actually happened. You can use that system to manage tasks, delegate work to your team, log results and collect audit evidence, and collect/alert on performance metrics. And with the help of a security management platform, such as Aptible Comply, it’s easy to understand exactly what you need to do, step-by-step, to run your security program and maintain your commitments.
Helping your team understand how security management will help the business grow is important for building support and prioritizing investment in security. And when you have security management in place you’ll want to showcase these efforts and make them discoverable for customers to find. Some potential benefits to discuss with your team:
Gain access to new markets. In B2B, as you grow, you’ll want to capture customers with higher annual contract values (ACVs) - bigger logos, more prestigious social proof. Getting started early with security management will fast-track you when you want to get a security certification or demonstrate that you have enterprise-level security processes. This unlocks high-value prospects in new industries and regions, adding new pipelines that will have huge impacts on future revenue. In B2C, security management puts the groundwork in place for accessing the EU (GDPR), the healthcare industry (HIPAA), building out your payments stack (PCI), and other strategic plays.
Breeze through vendor security assessments (VSAs). B2B vendor security assessments are a headache - time consuming at best and obvious demonstrations of your shortcomings vs. competitors at worst. Many early teams struggle to know what to say. Once you do the legwork to put a security management system in place, you’ll have everything you need to have competent, confident answers and win the business.
Reduce your risk of regulatory investigation, enforcement, and fines. We mentioned healthcare (HIPAA) and Europe (GDPR) above, but the FTC also regulates privacy and security (as Uber found out in 2017 and 2018). Claiming to “take security seriously” while failing to implement what the FTC interprets as “reasonable security measures” may expose you. (The CFPB also used to take an interest in security claims, but that’s presumably not going well.)
Reduce your risk of costly breaches and lost customers. For less established companies, the negative signaling of a messy, public security breach can be extremely harmful. Exposing data can lead to lawsuits, and eroding customer trust leads to churn. But good security management helps measure those risks and reduce them over time.
Security is a process, not a product. Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products. The trick is to reduce your risk of exposure regardless of the products or patches. - Bruce Schneier, “The Process of Security"
In this guide, we’ll use the term “security control” (or just “control”) to refer to one of these processes. Think of a control as a safeguard or a countermeasure - something you do to protect data. Controls come in different flavors:
Administrative or operational controls are processes primarily implemented by people, like risk assessment and treatment workflows, security awareness training programs, incident response and business continuity planning and testing, etc.
Technical controls are primarily implemented in software or hardware, using technology. Whether a technical control is appropriate or effective for a given system or architecture depends on factors like the type of system (SaaS services, app, database, EC2 instance, S3 bucket, etc.), the context and usage of that system, the sensitivity of the data it processes, and the risks the organization faces. Examples of technical controls are multi-factor authentication for SaaS services, MDM-enforced disk encryption for laptops and phones, encryption in transit for web and network services, role-based access controls for web applications, and so on.
Physical controls (e.g., locked doors, alarm systems, fences, etc.) relevant to the physical security of data and the systems that process data. Much of the SaaS ecosystem depends on AWS, Google, and Microsoft for physical security of their data centers and networks.
A robust security management program includes a mix of each type. For startups that are largely cloud-based and going from zero to a compliance audit like SOC 2 or ISO 27001, the gap and readiness work almost exclusively involves operational and technical controls.
It’s somewhat misleading to refer to a control as exclusively operational or exclusively technical (or even physical). In order for a control to be effective, someone or something has to check it periodically, what we refer to broadly as an “audit.” If you’ve ever heard of Plan-Do-Check-Act, the concept of security as a process is similar.
This process model of security can be used to describe a control in terms of its design, operation, and audit. So in a sense, even technical or physical controls have operational components: the audit check.
Design: During the Design stage of a control (or entire security program), you plan out what your intended result is. This can be described in text, like a policy and accompanying instructions (procedures). For example, you may decide to encrypt all work laptops and require a password to log on, or you may decide to implement 2FA for G Suite. Instead of just having a policy that laptops must be encrypted, security-as-a-process design will also include a process (workflow) for enrolling new laptops in mobile device management (MDM) and a process for verifying MDM on a regular basis (perhaps quarterly).
Operate: The Ops stage is when you actually take the output of Design and bring it to life. Run those security processes. Enroll those laptops, perform those checks. The output of this phase are audit records showing what processes/workflows were completed or not, who they were assigned to, etc.
Audit: At the level of a single control, Auditing is checking the operation of that control. Is it working properly? The policy in the example above (encrypt laptops) has an operational workflow component (enroll new laptops in MDM) and an audit workflow component (check enrollment in MDM). The audit component is a backstop to help build confidence that the operational component is working. If the check passes, store the record of the check and the evidence for later. If it fails, you’ll want to track the nonconformity and follow up on a fix. At the level of an entire security management system, Auditing is a separate workflow consisting of checking the design and operation of many controls. Whether auditing a single control or many, checking the operation of each control helps you fix controls that aren’t working and get rid of controls that have become obsolete.
If you sell to enterprise companies, you’re familiar with the joys and sorrows of vendor security assessments (VSAs), and have probably been asked for an audit or compliance report or certification. You’ve also probably seen compliance pages that describe organizations’ numerous compliance achievements - for example, take a look at Slack's security page.
Compliance and security are often referred to together, and confused, since many compliance frameworks are designed to verify whether your practices match a particular security standard through audits.
But don’t confuse the two - while some audits might be good proxies to judge security acumen, it’s possible to satisfy the minimum requirements for a security protocol (including ISO 27001 and SOC 2 which are common standards today), yet still be far from being fully secure. Compliance is someone else’s idea of what security looks like, and often much is lost in translation.
Because of this gap between compliance and security, compliance is often a poor approximation of security. Yet it has all but replaced security as the end goal. Compliance itself is treated like a series of checkboxes barely connected to how a business operates or produces value: policies nobody reads, training nobody remembers, and controls that look good on paper but don’t actually work. Thousands of dollars and hours later, the result is a lot of compliance theater and a gnawing sense that even with your audit report in hand, you’re barely more secure than when you started.
When Compliance Isn’t Enough: A Look at the Equifax Breach
Despite having an ISO 27001 certification, Equifax suffered a massive security breach in 2017. Investigations showed that the company’s vulnerability-management process failed. Worse, despite knowing about an Apache Struts vulnerability in a custom-built internet-facing consumer dispute portal, it was never patched. According to an official report on the incident, attackers were able to move within Equifax’s network and find unprotected credentials for other databases, and exfiltrate unencrypted personally identifiable information (PII). Equifax did not notice the exfiltration because its network monitoring device was inactive due to an expired security certificate. The attackers found unencrypted personally identifiable information (PII) and transferred it undetected because of an expired security certificate.
Equifax checked enough boxes to get an ISO 27001 certification, but became an example of what can happen when a company lacks the training, culture or willpower to operate effectively. The House report found “a lack of accountability and no clear lines of authority in Equifax’s IT management structure existed, leading to an execution gap between IT policy development and operation.” They had policies, but didn’t enforce them. They had monitoring, but it didn’t work.
As the House report put it, “ Equifax’s aggressive growth strategy and accumulation of data resulted in a complex IT environment. Equifax ran a number of its most critical IT applications on custom-built legacy systems. Both the complexity and antiquated nature of Equifax’s IT systems made IT security especially challenging.” And when security operations failed to scale, they gave attackers access to the personal information of 148+ million consumers.
Privacy management has a lot of overlap with security management, and deserves its own guide. For now, know that the work you do for the latter will help you meet privacy requirements for HIPAA, GDPR, CCPA, and the SOC 2 Privacy Trust Services Criteria.
Throughout this guide we’ll refer to “security management,” but in a lot of places you can think “security and privacy management.” The concepts of developing control over data by pairing accountability with clear workflows and governance checks are similar.