Share this article
Do you need penetration testing for compliance?
This article is authored by Software Secured, a penetration testing provider and Vanta partner.
A lack of compliance is increasingly becoming a major barrier for sales, forcing security directors to be more in tune with their organization’s revenue and growth goals than ever before. To help ease this pressure, companies are seeking to fulfill compliance requirements faster.
In this article, we’re deep diving into the two most common security testing options that companies employ for their compliance initiatives: penetration testing and vulnerability scanning. We’ll also do a comparison on which one is most valuable to your project.
What is penetration testing?
When you’re beginning to work on earning your compliance, you’ll likely be informed by your auditor or compliance team that you should consider doing a penetration test. Some will say you need a penetration test. A penetration test is a comprehensive security assessment done by ethical hackers to measure the security defenses that you currently have in your systems.
Typically, penetration testing involves testing all your security controls such as authentication, authorization, integrity, and confidentiality against industry standards. A good penetration test should also test your application’s business logic and ensure there are no bypasses that can lead to serious issues.
Penetration testing can be conducted on all types of systems, including web and mobile applications, IoT devices, infrastructures, and networks. There are various types of penetration tests such as black box, gray box, and white box testing that approach the test in different ways, but all leveraging a human hacker to do the testing.
What is vulnerability scanning?
When a company is debating on the type of security test that they want to conduct, the choice is usually made between penetration testing or vulnerability scanning. Using a vulnerability scanner means employing an automated tool that identifies high-level vulnerabilities in your application. This is good to know and to keep in mind as you learn about the nature of each compliance framework below.
The difference between a prescriptive and descriptive compliance framework
All compliance frameworks cover different areas and have different requirements. As such, the way that penetration testing is suggested or required also varies across each framework. To better understand this, it’s important to know that compliance frameworks can either be prescriptive or descriptive in how they approach the security testing requirement.
Prescriptive compliance frameworks
Prescriptive frameworks are extremely helpful because they outline exactly what you need to do. There is no beating-around-the-bush. There are clear outlines for what constitutes a pass or a fail on your compliance. This makes it easy to know if you should get a penetration test, vulnerability scan, or neither.
Descriptive compliance frameworks
Descriptive frameworks, on the other hand, are much more vague. They often outline a recommendation to complete a form of security testing, but they don’t clarify the type of test that is needed or on which areas of your system(s) you need to have tested.
- SOC 2
- ISO 27001
What are the security requirements for each compliance framework?
Unsure if you need penetration testing or vulnerability scanning for your upcoming compliance audit? Customers who turn to Software Secured are often concerned about what that entails for each different compliance framework. Let’s dive into the most common compliance frameworks that our customers ask us about, including PCI DSS, HIPAA, SOC 2, and ISO 27001.
PCI DSS stands for the Payment Card Industry Data Security Standard. It is a standard for any company (digital or non-digital) that manages or stores cardholder data from any payment card provider (including Mastercard, VISA, American Express, Discover, and JCB). This framework is very prescriptive in nature and is very actionable for developing your security program. There are four compliance reference levels built into this framework:
- Level 1 is the highest level. It is for any merchant who processes over six million transactions annually OR any company that has suffered a data breach resulting in the capture of cardholder data. This level requires yearly penetration testing and quarterly vulnerability scans, among other security requirements.
- Level 2 is for any merchant who processes between one to six million transactions annually. At this level, merchants must complete quarterly security scans and a yearly self-assessment questionnaire.
- Level 3 is for any merchant who processes between 20,000 to one million transactions annually. Security testing requirements are the same as level 2.
- Level 4 is for any merchant who processes less than 20,000 transactions annually. There is no security testing requirement, but it is highly recommended to conduct the testing required in levels 2 and 3.
Even at levels that don’t require penetration testing, it is still recommended. No matter how many transactions your business processes each year, if you suffer a data breach that exposes customer cardholder data, you are automatically assigned to Level 1 which includes very strict and specific security requirements. This also may include a forensic investigation and other possible consequences that arise from your breach, such as legal fees, reputation risk, fines from card processing companies, and possible loss of card processing privileges (for companies that have experienced a breach multiple times).
The Health Insurance Portability and Accountability Act (HIPAA) is a major compliance framework for any company handling sensitive Protected Health Information (PHI) about their users. It is relevant to all covered entities (ie. doctors, nurses, insurance companies) as well as business associates (ie. lawyers, accountants, IT personnel in the healthcare industry) that may have access to PHI. HIPAA has descriptive privacy and security rules, which identify the following requirements relevant to security testing:
Under the Security Rule
- There is a “General Rule” to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting e-PHI (PHI data available digitally). Within this rule is a specific requirement to “Identify and protect against reasonably anticipated threats to the security or integrity of the information.” There is no specific method that is recommended for identifying anticipated threats, though the framework does ask businesses to opt for a solution that considers the company’s size, complexity, capabilities, infrastructure, costs, and impact of potential risks to e-PHI. Businesses need to consistently review their security practices to ensure it is up to date with the changing technology, risk, and business environments.
- Under the “Risk Analysis and Management Rule,” a requirement asks companies to build a risk analysis process that includes a minimum of four activities around the evaluation, implementation, documentation, and maintenance controls for risk management. Like the General Rule, there is also no specific method recommended under this rule.
Both a penetration test and vulnerability scan can help meet both rules.
Under the Privacy Rule
- Among many other requirements, there is an Administrative Requirement in the Privacy Rule to ensure Data Safeguards are in place. This includes “maintain[ing] reasonable and appropriate administrative, technical, and physical safeguards to prevent intentional or unintentional use or disclosure of protected health information…” A regular penetration test or vulnerability scan may be able to prove that proper technical safeguards are in place.
SOC stands for System and Organization Controls, and is relevant for service organizations. It was developed by the American Institute of CPAs (AICPA) to measure if an organization’s practices are sufficient for safeguarding any customer data that they may access, store, or transmit. This framework is descriptive in nature.
- Reports on controls within a service organization that are relevant to the five “Trust Services Principles” including security, availability, processing integrity, confidentiality, and privacy of customer data.
- The framework looks at your internal controls, including your control environment, risk assessment, control activities, information and communications, and monitoring. Both penetration testing and vulnerability scanning can support the risk assessment control, in addition to a multitude of other criteria.
SOC 2 is offered with two types of reports:
1. A Type 1 report is a “snapshot in time” look at your organization’s controls. A one-time penetration test or vulnerability scan will suffice for a Type 1 report.
2. A Type 2 report continuously monitors your organization’s information and privacy controls, for at least 3 months, typically once a year for 12 month cycles. If you are practicing more frequent testing for a Type 2 report, you may consider Penetration Testing as a Service (PTaaS) for quarterly penetration testing, or you can continue purchasing a one-time pentest or vulnerability scan each year.
ISO 27001 was published by the International Organization for Standardization (ISO) to bring a benchmark for information security practices in enterprises. Companies that strive for ISO 27001 compliance need to renew this standard every three years at minimum. It is a descriptive framework.
There are many control requirements which can be tested and proven through various security testing methods in Annex A. For example, there are control requirements regarding:
- Handling digital and physical assets
- Appropriate limiting of employee access to data
- Proper encryption of sensitive data
- Logging and monitoring of software and known vulnerabilities
- Technical vulnerability management
- Network security management
- Security of information as it shared within and outside of the organization
ISO 27001 is incredibly thorough in the number of aspects that it looks to seek protection on, but it doesn’t recommend one specific solution for testing the implementation of those protections. Vulnerability scanning can cover most security requirements but organizations should opt for a penetration test as it can cover all requirements.
The security testing requirements under each compliance framework
There's a lot of information out there and security compliance is complex. Building a security program is an iterative process, here are some quick points to make this decision a little easier.
Pros of getting a penetration test
- Comprehensive penetration tests usually produce a higher number of true positives and no false positives
- Support with remediation following report delivery
- Will definitely meet the requirements for all compliance frameworks
- Can upgrade anytime to Penetration Testing as a Service (PTaaS), which runs a penetration test quarterly
- Support on completing self-assessment questionnaires and vendor security questionnaires
- Assists in addressing other areas of your program to improve for compliance (i.e. logging and monitoring, authentication and authorization, etc).
- Supports global sales expansion (ie. organizations in Europe can have more stringent requirements around data security and privacy)
Cons of getting a penetration test
- High-quality penetration tests can get expensive
- As any manual test, penetration tests take more time to schedule and execute
Is a vulnerability scan sufficient for compliance?
In very rare cases, a vulnerability scan is enough. For example, if your client base isn't concerned with how their data or PII is secured. Or, if your company is focused solely on compliance and not investing in strong security measures for other business needs.
Pros of getting a vulnerability scan
- Much more affordable for smaller businesses.
- Little to no onboarding time after the tool is downloaded.
- Can be done in-house with a DAST tool.
- Faster results, usually within 24 hours.
Cons of getting a vulnerability scan
- May not be suitable for all types of compliance
- Only finds high-level vulnerabilities so potentially leaves deeper, unidentified security gaps
- Often produces false positives, which adds administrative burden to your technical team
Things that both will provide:
- A report outlining the vulnerabilities, often both in an online dashboard and a downloadable report file (ie. .docx, html, pdf, etc.).
- Both will work with almost any programming language or framework.
The ultimate answer
If you have the budget and time, getting a penetration test is your safest bet. Not only will you find more vulnerabilities, but you will also receive support for remediating these security gaps before your compliance audit. You will have much higher confidence in the software you are delivering and you will prove your commitment to security to your enterprise clients. Having a better score on your compliance certification will help you close more sales - so think of it as an investment for your future revenue.
About Software Secured
Software Secured is a leading provider of penetration testing services. Based in Canada, they are specialized at helping fast-growing SaaS companies conduct penetration tests for compliance, closing enterprise deals, secure code deployment, and securing investment rounds. If you’re interested in learning more about their penetration testing services, contact them to book a meeting here.
Determine whether the GDPR applies to you and if so, if you are a processor or controller (or both)
Do you sell goods or service in the EU or UK?
Do you sell goods or services to EU businesses, consumers, or both?
Do you have employees in the EU or UK?
Do persons from the EU or UK visit your website?
Do you monitor the behavior of persons within the EU?
Create a Data Map by taking the following actions
Identify and document every system (i.e. database, application, or vendor) which stores or processes EU or UK based personally identifiable information (PII)
Document the retention periods for PII in each system
Determine whether you collect, store, or process “special categories” of data
Determine whether your Data Map meets the requirements for Records of Processing Activities (Art. 30)
Determine whether your Data Map includes the following information about processing activities carried out by vendors on your behalf
Determine your grounds for processing data
For each category of data and system/application have you determined the lawful basis for processing based on one of the following conditions?
Take inventory of current customer and vendor contracts to confirm new GDPR-required flow-down provisions are included
Review all customer contracts to determine that they have appropriate contract language (i.e. Data Protection Addendums with Standard Contractual Clauses)
Review all in-scope vendor contracts to determine that they have appropriate contract language (i.e. Data Protection Addendums with Standard Contractual Clauses)
Have you performed a risk assessment on vendors who are processing your PII?
Determine if you need to do a Data Protection Impact Assessment
Is your data processing taking into account the nature, scope, context, and purposes of the processing, likely to result in a high risk to the rights and freedoms of natural persons?
Review product and service design (including your website or app) to ensure privacy notice links, marketing consents, and other requirements are integrated
Does the notice to the data subject include the following items?
Does the notice also include the following items?
Do you have a mechanism for persons to change or withdraw consent?
Update internal privacy policies to comply with notification obligations
Update internal privacy notices for EU employees
Determine if you need to appoint a Data Protection Officer, and appoint one if needed
Have you determined whether or not you must designate a Data Protection Officer (DPO) based on one of the following conditions (Art. 37)?
If you export data from the EU, consider if you need a compliance mechanism to cover the data transfer, such as model clauses
If you transfer, store, or process data outside the EU or UK, have you identified your legal basis for the data transfer (note: most likely covered by the Standard Contractual Clauses)
Have you performed and documented a Transfer Impact Assessment (TIA)?
Confirm you are complying with other data subject rights (i.e. aside from notification)
Do you have a defined process for timely response to Data Subject Access Requests (DSAR) (i.e. requests for information, modification or deletion of PII)?
Are you able to provide the subject information in a concise, transparent, intelligible and easily accessible form, using clear and plain language?
Do you have a process for correcting or deleting data when requested?
Do you have an internal policy regarding a Compelled Disclosure from Law Enforcement?
Determine if you need to appoint an EU-based representative, and appoint one if needed
Have you appointed an EU Representative or determined that an EU Representative is not needed based on one of the following conditions?
If operating in more than one EU state, identify a lead Data Protection Authority (DPA)
Do you operate in more than one EU state?
If so, have you designated the Supervisory Authority of the main establishment to act as your Lead Supervisory Authority?
Implement Employee Trainings to Demonstrate Compliance with GDPR Principles and Data Subject Rights
Have you provided appropriate Security Awareness and Privacy training to your staff?
Update internal procedures and policies to ensure you can comply with data breach response requirements
Have you created and implemented an Incident Response Plan which included procedures for reporting a breach to EU and UK Data Subjects as well as appropriate Data Authorities?
Do breach reporting policies comply with all prescribed timelines and include all recipients i.e. authorities, controllers, and data subjects?
Implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk
Have you implemented encryption of PII at rest and in transit?
Have you implemented pseudonymization?
Have you implemented appropriate physical security controls?
Have you implemented information security policies and procedures?
Can you access EU or UK PII data in the clear?
Do your technical and organizational measure ensure that, by default, only personal data which are necessary for each specific purpose of the processing are processed?
Develop a roadmap for successful implementation of an ISMS and ISO 27001 certification
Implement Plan, Do, Check, Act (PDCA) process to recognize challenges and identify gaps for remediation
Consider ISO 27001 certification costs relative to org size and number of employees
Clearly define scope of work to plan certification time to completion
Select an ISO 27001 auditor
Set the scope of your organization’s ISMS
Decide which business areas are covered by the ISMS and which are out of scope
Consider additional security controls for business processes that are required to pass ISMS-protected information across the trust boundary
Inform stakeholders regarding scope of the ISMS
Establish an ISMS governing body
Build a governance team with management oversight
Incorporate key members of top management, e.g. senior leadership and executive management with responsibility for strategy and resource allocation
Conduct an inventory of information assets
Consider all assets where information is stored, processed, and accessible
- Record information assets: data and people
- Record physical assets: laptops, servers, and physical building locations
- Record intangible assets: intellectual property, brand, and reputation
Assign to each asset a classification and owner responsible for ensuring the asset is appropriately inventoried, classified, protected, and handled
Execute a risk assessment
Establish and document a risk-management framework to ensure consistency
Identify scenarios in which information, systems, or services could be compromised
Determine likelihood or frequency with which these scenarios could occur
Evaluate potential impact of each scenario on confidentiality, integrity, or availability of information, systems, and services
Rank risk scenarios based on overall risk to the organization’s objectives
Develop a risk register
Record and manage your organization’s risks
Summarize each identified risk
Indicate the impact and likelihood of each risk
Document a risk treatment plan
Design a response for each risk (Risk Treatment)
Assign an accountable owner to each identified risk
Assign risk mitigation activity owners
Establish target dates for completion of risk treatment activities
Complete the Statement of Applicability worksheet
Review 114 controls of Annex A of ISO 27001 standard
Select controls to address identified risks
Complete the Statement of Applicability listing all Annex A controls, justifying inclusion or exclusion of each control in the ISMS implementation
Continuously assess and manage risk
Build a framework for establishing, implementing, maintaining, and continually improving the ISMS
Include information or references to supporting documentation regarding:
- Information Security Objectives
- Leadership and Commitment
- Roles, Responsibilities, and Authorities
- Approach to Assessing and Treating Risk
- Control of Documented Information
- Internal Audit
- Management Review
- Corrective Action and Continual Improvement
- Policy Violations
Assemble required documents and records
Review ISO 27001 Required Documents and Records list
Customize policy templates with organization-specific policies, process, and language
Establish employee training and awareness programs
Conduct regular trainings to ensure awareness of new policies and procedures
Define expectations for personnel regarding their role in ISMS maintenance
Train personnel on common threats facing your organization and how to respond
Establish disciplinary or sanctions policies or processes for personnel found out of compliance with information security requirements
Perform an internal audit
Allocate internal resources with necessary competencies who are independent of ISMS development and maintenance, or engage an independent third party
Verify conformance with requirements from Annex A deemed applicable in your ISMS's Statement of Applicability
Share internal audit results, including nonconformities, with the ISMS governing body and senior management
Address identified issues before proceeding with the external audit
Undergo external audit of ISMS to obtain ISO 27001 certification
Engage an independent ISO 27001 auditor
Conduct Stage 1 Audit consisting of an extensive documentation review; obtain feedback regarding readiness to move to Stage 2 Audit
Conduct Stage 2 Audit consisting of tests performed on the ISMS to ensure proper design, implementation, and ongoing functionality; evaluate fairness, suitability, and effective implementation and operation of controls
Address any nonconformities
Ensure that all requirements of the ISO 27001 standard are being addressed
Ensure org is following processes that it has specified and documented
Ensure org is upholding contractual requirements with third parties
Address specific nonconformities identified by the ISO 27001 auditor
Receive auditor’s formal validation following resolution of nonconformities
Conduct regular management reviews
Plan reviews at least once per year; consider a quarterly review cycle
Ensure the ISMS and its objectives continue to remain appropriate and effective
Ensure that senior management remains informed
Ensure adjustments to address risks or deficiencies can be promptly implemented
Calendar ISO 27001 audit schedule and surveillance audit schedules
Perform a full ISO 27001 audit once every three years
Prepare to perform surveillance audits in the second and third years of the Certification Cycle
Consider streamlining ISO 27001 certification with automation
Transform manual data collection and observation processes into automated and continuous system monitoring
Identify and close any gaps in ISMS implementation in a timely manner
Download this checklist for easy referenceDownload Now
Determine which annual audits and assessments are required for your company
Perform a readiness assessment and evaluate your security against HIPAA requirements
Review the U.S. Dept of Health and Human Services Office for Civil Rights Audit Protocol
Conduct required HIPAA compliance audits and assessments
Perform and document ongoing technical and non-technical evaluations, internally or in partnership with a third-party security and compliance team like Vanta
Document your plans and put them into action
Document every step of building, implementing, and assessing your compliance program
Vanta’s automated compliance reporting can streamline planning and documentation
Appoint a security and compliance point person in your company
Designate an employee as your HIPAA Compliance Officer
Schedule annual HIPAA training for all employees
Distribute HIPAA policies and procedures and ensure staff read and attest to their review
Document employee trainings and other compliance activities
Thoroughly document employee training processes, activities, and attestations
Establish and communicate clear breach report processes
to all employees
Ensure that staff understand what constitutes a HIPAA breach, and how to report a breach
Implement systems to track security incidents, and to document and report all breaches
Institute an annual review process
Annually assess compliance activities against theHIPAA Rules and updates to HIPAA
Continuously assess and manage risk
Build a year-round risk management program and integrate continuous monitoring
Understand the ins and outs of HIPAA compliance— and the costs of noncompliance
Download this checklist for easy referenceDownload Now
FEATURED VANTA RESOURCE
The ultimate guide to scaling your compliance program
Learn how to scale, manage, and optimize alongside your business goals.