Aptible logoUse CasesCustomers
Schedule a Call
Security Management Fundamentals

Chapter 03

Security Management Fundamentals

Security Management Fundamentals

This section will help you set the stage for your new security management program before you start designing it. Use it to understand scope, governance, and risk so you can move forward within the right parameters for your company.

Setting Scope of Security Management

We start with setting the scope of your security management system, as this is when you decide what data, technology, and people your policies, procedures, and practices will cover. This scope definition should always be near the top of your policy so your customers and security team can easily refer to it.

Some protocols clearly define their scope, like HIPAA, the GDPR, and the CCPA. For voluntary certification programs like ISO 27001 and SOC 2, you have more discretion. Whichever you’re working toward, you should aim to consolidate the use of sensitive data into as few systems as possible.

Case Study: Mode Analytics, SOC 2, and Expanding the Scope for GDPR

Mode Analytics is a data-analysis platform that combines a powerful, web-based SQL editor with charting and sharing tools. They partnered with Aptible to create a system of record for their SOC 2-audited security program, and to expand its scope to cover the GDPR.


When Mode started with Aptible, it already had a security management program in place, scoped as needed to go through a SOC 2 examination. This included core business functions like product development, incident response, and business continuity; its internal teams related to these functions, including Engineering, Ops, Customer Success, and People Ops; and the data related to its product, including customer data and audit logs.

But when Mode needed to ensure that it was complying with the GDPR, it needed to broaden the scope of its security management program in order to cover the information and processing activities that weren’t in scope for its SOC 2 audit. This expanded scope now required business functions like marketing and sales; and their use of systems that touched EU personal data such as CRMs, web monitoring and analytics, advertising platforms, and more. 

By realizing that the first step to GDPR compliance was to expand the scope of its security management program, it was easy for Mode to determine what to do from there in order to reassess its risks, choose additional security and privacy controls, and self-audit its GDPR compliance.

Scoping out your security management program is not just a mental exercise - the output includes documentation that will be useful soon, including an asset inventory and the ability to start a vendor inventory and begin automating vendor management processes. With these in hand, you’re ready to analyze your risks and decide on mitigating security controls.

Assessing Risk and Selecting Controls

If setting scope and writing down what data and systems you want to protect is the most fundamental starting point for security management, managing risk is a close second. Once you’ve scoped out your security management program, going through the process of articulating bad things you’d like to prevent from happening will help you make pragmatic decisions, communicate priorities to your team, and make the case for additional resources to fight risk. Because risk assessments are crucial in helping organizations make information-security decisions, every protocol requires that you have repeatable, well-understood controls in place to prioritize and manage risk.

Why Perform a Risk Assessment?

If you are subject to a security or privacy protocol, you are already required to implement controls related to data security and privacy - so what’s the benefit of a risk assessment if you’re already complying with a protocol?

The answer is that because no protocol is perfect or complete, your decisions about internal security and privacy will depend on the actual threats you face and vulnerabilities you are subject to - and often, these are not covered by the base requirements of a protocol. HIPAA, for example, has nothing to say about multi-factor authentication (MFA or 2FA), a practice now considered a baseline prerequisite for accessing systems with sensitive information. These gaps in protocols exist in part due to the slow speed at which they are updated, resulting in protocols that don’t ever reflect the state of the art in security. 

Because no protocol will ever be complete, it’s essential that you improve your security posture by implementing controls that relate directly to -- and mitigate -- your actual risks.

Risk assessment is fundamentally a tool for helping you decide what to do next. A risk assessment helps you determine which additional controls you should implement. Suppose, for example, that your board has approved a budget of $20,000 for security projects over the next year, and you are in charge of allocating it--what do you spend it on? Do you engage a penetration tester? Or invest in additional security awareness training? Or invest in more software (like MDM)? Your risk assessment will help you with that decision--it gives you the information you need in order to identify the controls you should implement to have the biggest impact on your organization.

Common Components of Risk Assessments

Many information security risk assessment methodologies use the same core set of steps:

  1. Identify the threats you face -- i.e., the circumstances that can exploit vulnerabilities in your information systems and processes

  2. Determine your own tolerance for risk -- this involves identifying acceptable levels of risk based on your internal resources and objectives

  3. Analyze your threats by reviewing the likelihood that the threat will occur and the impact on your organization if the threat does occur, given what you know about existing controls

  4. Calculate some overall risk value for each threat based on the threats’ impacts and likelihoods

  5. Use that information to prioritize security investments

There are a number of different ways to estimate the impact (and likelihood) of a risk. These can be measured qualitatively (low, medium, high), quantitatively ($5,000; 50%)The Verizon Data Breach Investigations Report (DBIR) can help you quantify the cost and effects of potential vulnerabilities. 

The Output of Your Risk Assessment

An effective risk assessment should give you the information you need to make decisions related to information security. Remember the hypothetical described above involving your board authorizing $20,000 in security spending? Your risk assessment should give you clear guidance on how much risk reduction you’re getting for your dollar.

Additionally, your risk assessment should also give you:

  1. A high-level view of your organization’s overall risk -- beyond a risk-by-risk summary, should be able to determine your company’s overall risk (compared to its tolerance).

  2. Results that are comparable over time, allowing you to determine the trend that your organization is going in -- are you getting riskier or less risky over time?

Should You Hire Someone to Perform a Risk Assessment?

Although many startups pay consultants to perform risk assessments for them, there are real limitations - and problems - with this approach.

It’s often the case that external parties aren’t sufficiently familiar with your systems to properly identify and assess your risks. Even when outside parties send you pre-assessment questionnaires to attempt to identify your actual risks, these often consist of boilerplate or general sets of issues (like the OWASP Top 10 list of web-app vulnerabilities). These questionnaires rarely result in a complete list of the threats you face and should analyze.

As a result, risk assessments performed by outside parties often focus on risks that are far too generic (e.g., “web-app vulnerability”), or contain risk determinations that are too undifferentiated (e.g., a result that most risks are of “medium” severity). While these results might be accurate, there is a meta risk that they don’t actually represent your organization.

If you decide to hire an outside organization to perform your risk assessment, make sure it understands the nuances of your security management program and information systems - the details of your web architecture, your SaaS vendors, you devices and other assets, etc. Moreover, just knowing compliance isn’t enough - get their references and ask about the quality of assessments they’ve done, including whether they made measurable, actionable recommendations.

Checks and Balances: Accountability Through Governance

How do we create a security management system we have confidence in? One that we trust?

Governance is the architecture of processes that creates oversight and accountability in your security management program. It's a meta-set of security decisions and actions that enable the "management" part of your security management program. Governance activities include:

  • Clearly defining roles and responsibilities for security and privacy management

  • Approving official security management documentation (policies, procedures, workflows, etc.) and updating it regularly

  • Demonstrating management/board commitment to security

  • Selecting security metrics and managing improvement

  • Overseeing security management operations

  • Auditing (internal auditing, certifications, VSAs, etc.)

For governance to work, you must have both a clear framework and cultural buy-in. Clearly communicating why your security management program exists, and how it works, to your board, management, employees, customers, and other stakeholders will help you at each stage as you scale. 

While each major protocol (like ISO 27001, SOC 2, GDPR, HIPAA, etc.) has different governance requirements, in the sections below we cover the Aptible Comply governance baseline - the basics you’ll want to implement no matter what.

Clear Roles and Responsibilities

Every security protocol has its own requirements for roles and responsibilities. If you need to comply with HIPAA or GDPR, you will need a security officer and a privacy officer, or a data protection officer, respectively. At a bare minimum, you want to clearly assign ultimate accountability for security to a single person at all times. This can be a head of security, a director, a VP, or any member of your workforce you designate as your security officer. 

The illustration below will help you assign roles to people based on the oversight your protocols require. It’s fine to assign people to multiple roles if you’re still a small team. As you scale you can separate duties accordingly.


Security Team: The Security Team helps the Security Officer with all security-related tasks, such as reviewing vulnerabilities, performing regular security checks, helping coordinate audits, etc. The Security Officer acts as the team lead of the Security Team.

Incident Response Team: The Incident Response Team responds to security and privacy incidents. The Incident Response Team will generally overlap with the Security Team, the Engineering Team, and the Service Reliability Team.

Service Reliability Team: The Service Reliability Team is on-call for availability issues, business continuity, and disaster recovery.

Engineering Team: With regard to your security management program, the Engineering Team is responsible for following your secure system development policies and procedures, as they apply to software lifecycles.

Management Team: The Management Team is responsible for all governance activities.

Legal Team: The Legal Team is responsible for coordinating activities that have legal consequences - either as your counsel, or as your liaison with outside counsel. This is particularly important with regard to privacy matters, which are usually governed by mandatory regulatory frameworks.

Human Resources Team: The Human Resources Team is responsible for training management, and the workforce-member lifecycle (hiring and onboarding new workforce members, performing sanctions investigations, offboarding departing workforce members, etc.). At startups, the Human Resources Team also often takes on IT functions, such as device management.

Workforce members:  Everyone should be responsible for following policies and maintaining culture. 

Leadership from the Top

In order to promote a security-focused culture, all levels of your organization must view security as a necessary component of running your business. When the leadership of an organization views security as a cost -- rather than as an enabler of business -- it experiences a number of negative side effects, including:

  • Taking shortcuts to avoid thinking about -- and addressing -- security

  • Failing to perform risk assessments, and thus not having insights into their biggest vulnerabilities

It’s unlikely that any organization would forthrightly admit that it treats security as a second-class priority. But your leadership can create a dispirited security culture in a number of other ways, including, for example:

  • Treating a reported security issue as a pain or burden, rather than as an important issue that should be fixed

  • Penalizing individuals for reporting potential security issues

  • Making workforce members who suggest improvements to security feel unwelcome or unheard

  • Not defining the organization’s security goals or objectives

While security may not always be your leadership’s primary priority, security should always be balanced with your organization's overall business objectives and treated as an important element in most business decisions. And at a minimum, your leadership should attempt to foster an environment where security is respected and not ignored. This includes, for example, rewarding workforce members who consider security in their projects, including in new product development and in vendor procurement; establishing clear lines of reporting; hiring and retaining employees who can uphold company objectives; and holding people accountable for their responsibilities around security. Your leadership must also be committed to the psychological safety of employees by building trust and supporting employees’ need to solve complex security problems.

In order to create this kind of security-focused culture at your company, your leadership needs to be involved in security early and often.  There are a few key ways to get buy-in from your leadership, including the following.

  • Management training and expectation setting: One of the most important first steps in getting your leadership invested in security is through training and expectation-setting. Training is essential since many management teams aren’t used to incorporating security in their day-to-day activities. And expectation-setting is crucial so that your management team can point to well-defined, pre-established requirements related to security for justification in including security in projects.

  • Management reviews: Another way to involve leadership is in an annual management review. During a management review, your management team should review the design and operation of your security management program, and decide on any changes that should be made to improve your security management program.

  • Board involvement: Some compliance protocols explicitly include references to a board of directors--most explicitly, the AICPA’s update with the 2017 Trust Services Criteria, now based in large part on the COSO framework, includes specific requirements related to a board. But even where not required, it’s good to give regular security updates to your board (even if only as an annual report), as this will normalize security as another standard business process, and if you have buy-in from your board with regard to security, it will give you ammo to prioritize security with other members of your team.

Picking Good Security Metrics

Part of strong governance is being able to measure the success of your security management program. To do so, you must identify metrics that will prove your processes are - or aren’t - implemented correctly. There’s no one-size-fits-all when it comes to metrics, but we put together a list to get you started.

  • % of employees who were properly onboarded and off-boarded

  • % of employees who complete security training

  • % who have signed a security policy and procedure agreement

  • % of applicable devices properly enrolled in device management

  • # of security incidents

  • # of security incidents responded to in time and according to plan

  • # of closed issues per average vulnerability inventory

It’s likely your metrics will fall into two categories—some that are useful for benchmarking yourself against your previous position or industry standards, and some you’ll use to actively course-correct each evaluation period. Prioritize your list in terms of followup and put someone in charge of taking action when they underperform.

Resources for leveling up your security metrics

This post from Metricon X 2019 has plenty of useful information on how to think about security metrics. 

Depending on your customer base, your contracts may include service-level agreements (SLAs). This Markerbench post presents a perspective on how to apply these concepts to security. 


Two types of audits are crucial to maintaining governance and oversight: internal audits that help you check the efficacy of your own program, and external audits let a third party confirm things actually got done. Each protocol will have different requirements for external audits, but you can design a system internally that helps you prepare.

An important part of monitoring and auditing your systems internally is tracking nonconformities (anything that doesn’t meet one your requirements or policies) and planning to fix them. Nonconformities come in two flavors—those that result from a poorly designed security management program (i.e., your policy doesn’t satisfy a protocol requirement), and those that result from ineffective operations (i.e., you aren’t following your own policies).  

When you find a nonconformity or potential vulnerability, it must be managed and documented for regulatory purposes. You also need a system for following up on them and keeping responsible team members accountable for their resolutions. How you do this is up to you - some organizations use spreadsheets, while others use project-management tools (like Jira). Entities with the most sophisticated security management systems use tools that were built specifically for that purpose.


By taking action to address each of the areas covered in this guide for getting started with a security management program, you’ll be well-prepared for the most common security management challenges and how to overcome security roadblocks. While we hope this Part I helps you determine your immediate next steps for building a security management program, be on the lookout for Part II which will discuss designing security processes and controls within your organization. 

In the meantime, check out Aptible Comply to help you create a security management program. Comply organizes and automates security and privacy management into clear, simple processes that give you and your customers confidence. Schedule a demo to get started. 

Already underway with security management and searching for a way to showcase your compliance efforts? Create a profile for your company on the Aptible Trust Center.




ISO 27001




Start your security management journey now.

Get Started