Choosing infrastructure technology has traditionally involved a familiar set of questions. Does it meet the technical requirements? Will it handle the expected traffic? Is it compatible with the existing environment? What will it cost to deploy and maintain?
Security teams are adding another question to that process: how much do we know about the company behind the technology?
This is particularly relevant when a supplier provides technology that becomes part of important application infrastructure. An Application Delivery Controller (ADC), for example, may sit in the path of critical application traffic and remain in the infrastructure for years. The organization is therefore not only selecting software. It is establishing a long-term relationship with the company responsible for developing, maintaining, updating and supporting it.
For organizations handling sensitive information or critical digital services, this can lead to a much broader security review. Healthcare providers, universities, public-sector organizations and other security-conscious environments may ask vendors about their security policies, vulnerability management, internal controls, testing practices or incident response procedures before approving them.
Why Security Evidence Matters When Evaluating a Technology Vendor
A vendor security assessment is a review of the cybersecurity posture of a supplier. It can form part of a broader vendor risk assessment and may involve security questionnaires, technical discussions and requests for documentation that help the organization understand how the vendor manages security.
The depth of that assessment will vary considerably. A supplier of a low-risk business tool will not necessarily receive the same scrutiny as a company providing technology used in critical infrastructure.
But the underlying principle is simple: security claims are more useful when they can be supported by evidence.
A questionnaire may ask whether a vendor has an information security policy, a vulnerability management process or an incident response plan. For a more detailed assessment, the customer may also want evidence showing that those practices have actually been established.
Depending on the organization and the technology being assessed, this could include information about security policies, security testing, vulnerability management, architecture, data flows, access controls, incident response, supplier management or recognized security standards.
What Are Security Teams Actually Evaluating in a Vendor?
A vendor security questionnaire can cover a surprisingly broad range of areas. That is because the purpose is not simply to establish whether the supplier sells a cybersecurity product. The objective is to understand whether security is managed consistently across the organization that develops and supports the technology.
Several areas tend to become particularly relevant.
Security governance and risk management
One of the first things a security team may want to establish is whether cybersecurity has a defined place within the organization.
That can mean checking whether information security policies exist, whether responsibilities have been assigned, how security risks are identified and whether there are processes for reviewing those risks as the business, technology or threat landscape changes.
The question behind all of this is fairly straightforward: is security managed systematically, or only when a problem appears?
For technology vendors, this matters because product security, corporate infrastructure and customer support do not operate independently. They depend on decisions, responsibilities and controls across the company.
Corporate infrastructure and access control
Customers may also want to understand how a vendor protects the infrastructure used to develop, distribute and support its technology.
This does not require the vendor to disclose its network topology or internal configurations. What matters during an assessment is whether appropriate controls exist around areas such as administrative access, least privilege, credential management, logging, monitoring, asset management and access to sensitive systems.
There is a good reason for looking at this layer.
A security problem affecting a technology supplier can potentially originate outside the product itself. Development systems, repositories, administrative accounts, support platforms or other corporate assets can all become relevant to the overall risk relationship between customer and vendor.
Secure development and vulnerability management
For a software vendor, security also needs to continue throughout the lifecycle of the product.
Security teams may therefore ask whether software changes are reviewed before release, whether vulnerabilities are actively identified and evaluated, how security fixes are managed and whether third-party components are monitored for known vulnerabilities.
The presence of a vulnerability is not in itself evidence that a vendor has failed. Vulnerabilities can be discovered in practically any sufficiently complex software environment.
A more useful question is how the vendor responds when one is found.
Does it have a defined process to assess the issue? Can it determine the potential impact? Is there a mechanism for remediation, testing and distribution of the necessary update?
These practices are important because customers depend on the vendor not only at the point of purchase but throughout the useful life of the technology.
Security testing
Security testing provides another layer of assurance.
Depending on the vendor, risk and product, this may involve automated vulnerability analysis, dependency reviews, dynamic application testing, targeted assessments or penetration testing.
No individual testing technique proves that software is completely free from vulnerabilities. Security testing is more useful when it forms part of a continuous process: identifying weaknesses, analysing findings, correcting relevant issues and adapting testing as the product evolves.
This is why focusing exclusively on whether a vendor “does pentesting” can miss the wider picture. Penetration testing can be valuable, but it is only one element of a broader security management and vulnerability assessment strategy.
Third-party and supply-chain security
Very few technology companies operate without dependencies.
Software components, infrastructure providers, external services and other suppliers may all contribute to the systems used to develop or deliver a product. A vendor security assessment may therefore extend to how these third parties are considered and how relevant dependencies are monitored.
Understanding how a supplier approaches third-party risk can therefore provide additional context when evaluating its overall cybersecurity posture.
Incident response and resilience
Preventing incidents is important. Being prepared for them is equally important.
Security teams may want to know whether a vendor has an established incident response process and whether responsibilities exist for detection, investigation, containment, recovery and communication.
This becomes particularly relevant in environments such as healthcare or higher education.
A hospital evaluating infrastructure for important application services will naturally consider the operational impact of a security incident or prolonged disruption. A university may have a very different architecture, but it can face similar concerns across administrative applications, academic systems, research environments and large, diverse user populations.
In both cases, supplier security can become part of the technology decision because the consequences of choosing a vendor extend well beyond the initial deployment.
Vendor Security as Part of the Technology Selection Process
Vendor security assessment usually does not happen in isolation.
An organization may already have validated the technology, tested the software or confirmed that the solution satisfies its infrastructure requirements. Security review can take place in parallel with that technical evaluation or become another approval stage before procurement can move forward.
This explains why a technically suitable product may still need to be reviewed by cybersecurity, risk, compliance or procurement teams.
For the technical team, the question may be: does this ADC work in our environment?
For the security team, the question is different: are we comfortable introducing this vendor into our technology supply chain?
A mature selection process needs to answer both.
This is also the relationship between a vendor security assessment and the broader concept of a vendor risk assessment. Vendor risk can include operational, financial, legal, privacy or continuity considerations. A vendor security assessment focuses specifically on the cybersecurity dimension of that relationship.
For infrastructure that plays an important role in application delivery, that dimension can carry considerable weight.
Questions to Ask When Comparing ADC Vendors
When security forms part of an ADC selection process, these questions can help move the conversation from product claims to vendor assurance:
- Does the vendor have established information security policies and defined security responsibilities?
- Are secure development practices integrated into the software lifecycle?
- How does the vendor identify, evaluate and remediate vulnerabilities?
- Are third-party components and relevant dependencies monitored for security issues?
- Does the vendor perform regular security assessments?
- Is there an established incident response process?
- How are security updates and patches managed throughout the supported lifecycle?
- Can the vendor provide supporting security evidence when a customer’s cybersecurity team requires additional due diligence?
- Does the company follow, or is it working toward, recognized information security standards?
- How does the vendor protect confidential documentation shared during a security assessment?
There is no single answer that will fit every organization. The level of assurance required varies by sector and risk profile; what is proportionate for one deployment may be excessive, or insufficient, for another.
What matters is that the questions form part of the decision before the technology becomes another dependency that has to be managed later.
For technology vendors, being prepared to answer these questions and to support those answers with appropriate evidence, is becoming an important part of building trust with security-conscious organizations. This is also how SKUDONET approaches vendor security reviews
How SKUDONET Supports Vendor Security Assessments
At SKUDONET, security is not limited to the cybersecurity capabilities available within our ADC platform.
We apply security practices across the lifecycle of the technology we develop and maintain. These include secure development practices, review and validation of software changes, vulnerability management, monitoring of vulnerabilities affecting relevant third-party components, security testing, and the delivery of security patches and updates when required.
Security also applies to the company infrastructure supporting those activities. SKUDONET maintains internal security controls and an established incident response framework covering systems and information under our responsibility. Our internal Information Security Policy defines principles covering areas such as security governance, access management, vulnerability management, infrastructure security, data protection, logging, backups, incident management, and supplier security.
We also perform internal security assessments as part of our security work, using complementary testing approaches that evolve as the product and threat landscape change.
At the organizational level, SKUDONET is currently working toward ISO/IEC 27001:2022 certification and implementing an Information Security Management System aligned with the standard. We are also implementing security management requirements aligned with Spain’s National Security Framework (ENS) at medium level.
These initiatives are part of our ongoing work to formalize and strengthen how information security is managed across the company.
When an organization carries out a formal vendor security assessment, SKUDONET can provide additional security information and supporting documentation where appropriate. Information covering sensitive internal policies, procedures, architecture, or operational practices is handled under suitable confidentiality conditions.
The goal is straightforward: to give security teams the information they need to make an informed decision without exposing information that should remain protected.
Trusting the Company Behind the ADC
Selecting an ADC is not only a question of throughput, high availability, deployment options or licensing.
When that technology becomes part of important application infrastructure, the organization responsible for developing and maintaining it also becomes part of the equation.
For technology providers, that means trust increasingly has to be demonstrated, not simply stated.
Do you have questions about SKUDONET’s security practices? If your cybersecurity, infrastructure or procurement team needs additional information as part of a vendor security review, contact us. Our team can answer your questions and provide further security information where appropriate.
Cushions, left to right: replacement SE, original SE, Pro
![[RSS 1.0 Feed]](common/rss10.png){kind=small}
![[RSS 2.0 Feed]](common/rss20.png){kind=small}
![[Atom Feed]](common/atom.png){kind=small}
![[FOAF Subscriptions]](common/foaf.png){kind=small}
![[OPML Subscriptions]](common/opml.png){kind=small}
![[Hacker]](common/hacker.png){kind=small}
![[Planet]](common/planet.png){kind=small}