In the world of selling and implementing enterprise technologies and platforms, there is a common misconception that Request for Proposals (RFPs) are neatly siloed. If you are selling a firewall, it’ll be a security RFP; if you are selling a workflow engine, it’ll be a "functional" RFP. Atish Dash, CC, recently encountered a valuable reality check.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
My team and I recently responded to a standard enterprise platform RFP. It was for the implementation of a cloud computing platform that helps companies manage digital workflows for enterprise operations. We walked into the process with what had become a regulation mindset, expecting to focus primarily on crafting a response for core IT service management (ITSM) modules and automated workflows.
What we encountered instead was a procuring organization asking an extensive set of cybersecurity and technical questions along with data protection addendums and requirements – all in addition to the core functional requirements. The cybersecurity demands rivalled those of dedicated SOC 2 audits.
As part of the vendor bidding team, this salutary experience highlighted to me that, in modern enterprises, there is no such thing as a non-security or a purely functional RFP. It was a lesson: cybersecurity is now baked in at every level of the technology implementation lifecycle, regardless of the tool’s primary function.
Exploring the Mistake: It’s ‘Just’ a Functional Tool
When the RFP landed, our initial focus was on crafting a solution that showcased our implementation logic and specific business domain expertise. I was prepared to craft our response on how the platform would streamline operations and integrate with legacy databases and third-party systems. I viewed the platform as a utility and expected the questions to center on aspects such as its API integration capabilities, user-functionality customization, licensing and cost structure and implementation timelines.
The internal assumption was that security would be a check-box exercise; perhaps a brief look at our organization’s generic ISO 27001 certificate? However, the client procurement team viewed the platform as a massive new repository for sensitive data and thus a high-value target for cybersecurity threat vectors.
As I opened the cybersecurity annex of the RFP, its scope was breathtaking. The client didn’t just want to know if we were secure; they demanded proof of how not only we secured this specific platform but also what were our best practices in terms of securely developing and implementing it.
This presented us with a raft hitherto unencountered issues, most notably:
- Data Residency: As the platform would process employee data, I had to provide specific documentation on where the data lived and which legal jurisdictions applied.
- Access Governance: The client was unsatisfied solely with our use of SSO. I had to demonstrate our process for just-in-time (JIT) provisioning and how we remediated orphaned accounts.
- Logging and Monitoring: The requirement was clear: platform logs had to be ingested into their SIEM systems. I had to prove our capability to treat the platform as a critical node in their security operations center (SOC).
A Huge Upside
Answering these questions acted as a mirror for us, showing me exactly where our organizational maturity stood. During the process I discovered several blind spots that I’ve since realized are common across the industry. Crucially, I’ve subsequently been able to take remedial action:
- Policies Without Ownership: We had a data protection policy – but, when I looked for who was responsible for specific data objects within the new platform, I found a vacuum.
- Lack of Documented Resilience: I discovered that many of our critical security procedures were retained as tacit knowledge by a few key senior security engineers. When the RFP requested a platform-specific incident response plan, it became clear that we were relying on individual expertise rather than having a formalized, repeatable framework.
- Controls Without Evidence: I was aware that we rotated encryption keys, but the RFP procurement organization required documented proof of our existing process and methodology. Once again, I collaborated closely with my engineering lead to fully understand our secure software development lifecycle (SDLC) procedures and worked with them to create a process flow diagram showcasing our best coding practices, secret management techniques and deployment methodology.
For cybersecurity professionals, this shift in procurement of enterprise software is a signal. Cybersecurity is no longer just a department; it is a commercial and operational requirement. This is because cybersecurity is the “gatekeeper of revenue”. If, like me, you’re on the vendor side, any inability to answer these questions effectively can stall the RFP deal. I’ve seen deals freeze because the security annex couldn’t be either completed or delayed.
Addressing this required the support of senior management: without its commitment to funding governance, risk and compliance (GRC) tools and personnel, the gaps we discovered, like the lack of some of our internal documentation, would have remained unaddressed. However, when leadership understood the need to prioritize security, it ceased to be a pre-sales hurdle and became part of our organizational DNA. This support ensures that when an enterprise platform is implemented now, the security protocols are integrated by design, not as an afterthought.
Senior leaders also understand that they own the residual risk. My role is to provide the technical assurance, but management support ensures that the entire organization, from HR to finance, adheres to the controls we promise in the RFP.
How This Matters to All of Us
My recent experience has been a timely reminder that building a secure organization doesn’t require large enterprise budgets; it requires a culture of intentionality. For those on the vendor side, here are my three recommendations for achieving that:
- Bring Security in Early: I now ensure cybersecurity is part of the initial discovery phase of any platform implementation or our proposal response. This prevents cybersecurity debt from being building up in our pre-sales and delivery/implementation processes.
- Maintain RFP-Ready Documentation: I keep a live repository of our organizations’ ISO Certificates, Security Policies, Data Protection Agreements, RACI charts, and many more. We stay ready so we don’t have to get ready.
- Empower Cybersecurity Champions in Non-Security Roles: I’ve learned that we must not rely solely on the central cybersecurity team to answer every RFP. By identifying cybersecurity champions within the presales and engineering units, we’ve created a bridge; these individuals understand the technical product deeply but are trained to speak the language of risk, making the response process significantly faster.
Ultimately, this experience taught me that in today’s digital landscape, a platform’s functional value is only as strong as the security framework supporting it.
Atish Dash, CC, has over seven years of experience in technology consulting, cloud and cybersecurity, and program management across CPG, e-commerce/retail and nonprofit sectors. He has held roles spanning solutions consulting, technical implementation and business analysis, with expertise in cloud and network security, identity and access management, enterprise risk management and IT governance.
