We need an audit. Do we need security testing too?
You have been told your company needs a SOC report, and now someone is asking for a vulnerability scan or penetration test. You want to get through the audit successfully, without discovering a missing test or unresolved issue at the last minute. Before buying either, ask what the request is meant to answer. Which service is being audited? What systems support it? What security checks do you already perform, and what do those checks actually cover?
Testing can help you find weaknesses and show how your team responds to them. The work you need depends on your system, risks, commitments, and any requirements that apply to your business. Review those with your team and auditor rather than assuming every SOC audit calls for the same test.
Browse all Security Testing articles.
Vulnerability assessment identifies and evaluates weaknesses, often combining automated checks with review of the findings. Penetration testing goes further by testing whether selected weaknesses can be used to cause harm. It must be authorized, with an agreed scope and safeguards. Neither activity proves that a system is free of vulnerabilities.
Which parts of our business need to be checked?
Start with the service covered by your audit. If customers use a portal, what information can they see or change? Does it connect to billing, file storage, or another application? Ask your technical team whether it uses an API, a way for software systems to exchange information or request actions.
Those connections help you work out where a security problem could affect the service. Some checks may belong in your application test; others may need a different review or evidence from a provider. Being connected does not automatically mean every system needs the same test.
“But our cloud provider already gets audited. Doesn’t that cover us?” Their report can provide useful evidence about the services it covers. You still need to understand what your team controls, such as application access and configuration, and whether those areas have been checked.
Once you know what needs checking, agree with the testing provider on the systems, user roles, dates, exclusions, and safeguards. Get permission from the relevant owners before any testing starts.
- Web applications and APIs
- Review the customer workflows, user roles, administrative functions, and customer-data boundaries that matter. A test of public pages alone leaves important questions about authenticated services unanswered.
- External and internal networks
- External testing considers selected internet-facing systems; internal testing uses an agreed position within the environment. Clarify which networks, starting permissions, and segmentation boundaries are included.
- Cloud environments
- Separate cloud-provider controls from your organization’s configuration, identities, data permissions, and applications. Record the applicable provider restrictions and the services actually assessed.
- Kubernetes and containers
- Distinguish image scanning from workload configuration, cluster administration, and isolation review. Identify what the managed-service provider operates and what your platform and application teams control.
- AI-enabled features
- Identify new data flows, retrieval permissions, external model services, and action-taking integrations. A report issued before the feature was added may not address those changes.
- Automated testing, manual testing and red teaming
- Compare what each approach establishes, where methods combine, and what evidence is acceptable for your purpose, contract and applicable requirements. Tool labels alone do not determine coverage or acceptance.
Go deeper by topic
- Web application and API penetration testing: defining the right scope
- Internal and external network testing: two different questions
- Cloud security testing: scope, identity and shared responsibility
- Kubernetes security assessments: what a container scan leaves out
- AI application security testing: scope, permissions and reassessment
- Automated testing, manual penetration testing and red teaming: what is acceptable?
What will we need to show the auditor?
Ask your auditor what evidence is relevant to the controls being examined. Keep the testing scope and report, the issues found, and records showing what your team did about them. A report with no critical findings is useful only if you understand which systems and functions were checked.
If the report identifies a weakness, be ready to explain who is handling it, what has been fixed, and what remains open. A test report provides part of the evidence; it does not decide the outcome of the SOC examination.
Assign each finding an accountable owner and treatment date. Distinguish a deployed correction from a planned fix, a mitigating control, or a management decision to accept risk. Retest material findings and reconsider coverage after important changes to the service, its identities, or its data flows.
Monitor network and application security
Common gaps in security maintenance can leave networks and applications exposed:
- Delays in patching security flaws of operating systems and software;
- Use of insecure access protocols;
- Lapsed support, updates, or monitoring for security tools;
- Weak passwords for firewalls and other exposed services;
- Weak software inventory and change-management practices;
- Weak secure coding guidelines and QA review processes; and
- Lapses in IT Management’s adherence to security controls and protocols.
A maintained security program helps reduce these risks. Regular internal and external assessments can identify gaps and changes introduced by new systems or updates. Assign each confirmed finding an owner, a priority, and a remediation date; retest important fixes rather than treating the report as the end of the work.
Testing in compliance and assurance programs
Software as a Service (SaaS) providers, hosting facilities, and corporate networks handle sensitive business data. Testing can support the security and assurance programs used to protect that data, but its scope and frequency depend on the applicable requirements and risks.
Programs in which vulnerability management and testing may be relevant include the following. This is not a claim that every listed law or framework mandates the same assessment or penetration test. Confirm the applicable requirements with the responsible compliance team or auditor.
- Sarbanes-Oxley (SOX);
- Service organization reporting (SSAE 16 historical guidance and SOC 1);
- System and Organization Controls (SOC) 2 / 3;
- Payment Card Industry Data Security Standard (PCI DSS);
- Health Insurance Portability and Accountability Act (HIPAA);
- Gramm–Leach–Bliley Act (GLBA); and
- Federal Information System Controls Audit Manual (FISCAM).
Commonly identified risks
- Expired certificates, trust mismatches, or insecure TLS configuration;
- Unknown or unnecessarily open shares;
- Dormant user accounts that have not expired;
- Unnecessary open ports;
- Rogue devices connected to your systems;
- Scripts or scheduled tasks with unnecessary privileges;
- Servers allowing use of dangerous protocols;
- Incorrect permissions on important system files;
- Running of unnecessary, potentially dangerous services;
- Default passwords in use; and
- Unpatched services / applications.
Cybersecurity risk management readiness
Leadership should use testing results to ask concrete questions about readiness and response:
- How is leadership informed about the current level and business impact of cyber risks?
- Which risks matter most to the business, and who owns the plan to address them?
- How does our security program apply relevant standards and good practices?
- What incidents do we detect, and when should leadership be notified?
- Does our incident response plan cover the likely scenarios, and when was it last exercised?
Review the report with both technical owners and business leadership. Distinguish confirmed findings from assumptions, understand the systems and methods that were out of scope, and track remediation to closure. Testing provides evidence for decisions; it does not replace patching, monitoring, access management, or an exercised incident response plan.
Further reading: NIST SP 800-115: Technical Guide to Information Security Testing and Assessment.
Discuss your testing needs
Use the form below to describe your systems, business goals, and the type of help you need. Do not include passwords or sensitive technical details.
