You have spent two years building a product that a Fortune 500 company wants to buy. The commercial terms are agreed. Legal has reviewed the contract. Procurement sends you a vendor security assessment questionnaire.
Three weeks later, the deal is on hold. Your answers to their security questionnaire have triggered a detailed security audit. Six weeks after that, the deal falls through because you could not demonstrate adequate security controls.
This happens to Indian startups every day. Enterprise clients — particularly US, European, and large Indian conglomerates — have significantly raised their security standards for technology vendors. A product that worked two years ago now needs to pass vendor security assessments that startups were never designed to navigate.
Here are the eight most common failures — and exactly what to do about each one.
Failure 1: No Formal Security Policy Documentation
What the auditor asks: "Can you provide your Information Security Policy, Acceptable Use Policy, and Data Classification Policy?"
What most startups provide: A Notion page titled "Security" with a few bullet points, last updated in 2021.
Why this fails: Policies are the foundation of any security programme. They demonstrate that security is managed systematically, not ad hoc. Without documented, approved, and reviewed policies, every other security control is unverifiable.
- How to fix it:
Create a formal policy set with at least these five documents:
- Information Security Policy (master policy)
- Acceptable Use Policy
- Access Control and Password Policy
- Data Classification Policy
- Incident Response Policy
Each policy must have: a version number, an approval date, an approving authority (CEO/CTO signature), a review date, and distribution evidence showing employees have received it.
Failure 2: No Employee Security Training Records
What the auditor asks: "Please provide evidence of your security awareness training programme, including completion records for the past 12 months."
What most startups provide: "We had a Slack message about security last quarter" or "Our CTO does a session in onboarding."
Why this fails: Auditors are looking for a systematic, documented programme — not ad hoc conversations. ISO 27001 Annex A Control 6.3, SOC 2 CC1.4, GDPR, HIPAA, and PCI DSS all explicitly require documented security awareness training. Without records, you cannot demonstrate compliance regardless of how security-conscious your team actually is.
- How to fix it:
Implement a security awareness training platform that:
- Assigns training modules to all employees
- Records completion with timestamps
- Issues certificates per employee per module
- Generates audit-ready completion reports
One month of documented training is better than claiming two years of undocumented training. Start now.
Failure 3: Shared Credentials and Weak Access Controls
What the auditor asks: "How do you manage access to systems containing customer data? Do you use individual user accounts with multi-factor authentication?"
What most startups provide: "We have a team LastPass account" or "Our database password is shared on Confluence."
Why this fails: Shared credentials make it impossible to audit who accessed what and when. If a breach occurs, forensic investigation is impossible. This is a critical finding in almost every audit of early-stage startups.
- How to fix it:
- Individual accounts for every person in every system — no exceptions
- MFA enabled on all systems, especially those containing customer data
- Access reviewed quarterly — anyone who leaves must be off-boarded same day
- Principle of least privilege — people only have access to what they need
- Privileged access management for admin accounts
Failure 4: No Vulnerability Management Programme
What the auditor asks: "When did you last conduct a vulnerability assessment or penetration test? Can you provide the report and evidence of remediation?"
What most startups provide: "We have not done a formal penetration test" or a 3-year-old report with no remediation evidence.
Why this fails: Auditors want evidence that you actively manage security vulnerabilities — not just that you built secure code initially. Technology changes. New vulnerabilities emerge. Without regular testing, you cannot claim to know your current security posture.
- How to fix it:
- Commission an annual penetration test from a credible firm
- Conduct quarterly vulnerability scans of internet-facing systems
- Document remediation of all findings with closed dates
- Retain reports for at least 3 years
If you have never had a pentest, commission one before your next enterprise deal enters the procurement phase. It takes 4-6 weeks and the cost is a rounding error against a major enterprise contract.
Failure 5: Inadequate Data Backup and Recovery
What the auditor asks: "What is your backup policy? When did you last test restoration from backup? What is your RTO and RPO?"
What most startups provide: "We are on AWS so we assume it is backed up" or "We have daily backups but have never tested restoration."
Why this fails: Cloud providers like AWS, Azure, and GCP are responsible for the infrastructure — not your data. The shared responsibility model explicitly places data backup and recovery in the customer's hands. Assuming your cloud provider handles this is one of the most dangerous and common misunderstandings in startup security.
- How to fix it:
- Define explicit backup frequency (daily minimum, hourly for critical systems)
- Automate backups and verify they are completing
- Test restoration quarterly — not annually — and document the test
- Define your RTO (Recovery Time Objective) and RPO (Recovery Point Objective)
- Maintain at least one offline or separate-account backup copy
Failure 6: No Incident Response Plan
What the auditor asks: "If you had a data breach today, what is your incident response process? Who is notified, in what order, within what timeframes?"
What most startups provide: "Our CTO would handle it" or a vague description of escalation without documented procedures.
Why this fails: GDPR requires breach notification within 72 hours. DPDPA 2023 requires immediate notification to the Data Protection Board. HIPAA requires notification within 60 days. Without a documented, tested incident response plan, you will almost certainly miss these legal windows under the stress of an actual incident.
- How to fix it:
Create a one-page Incident Response Plan covering:
- How incidents are detected and reported internally
- The incident classification severity levels
- Who is the Incident Response Lead
- The notification chain — legal, management, affected customers, regulators
- The regulatory notification timeframes for each framework you operate under
- Post-incident review process
Run a tabletop exercise annually — walk your team through a hypothetical breach scenario and test whether your procedures work under pressure.
Failure 7: No Vendor/Third-Party Risk Management
What the auditor asks: "How do you assess the security posture of third-party vendors who access your systems or customer data? Do you have Data Processing Agreements (DPAs) in place?"
What most startups provide: "We use Stripe, AWS, and Intercom. They are big companies so they must be secure."
Why this fails: Your security is only as strong as your weakest third-party. If Intercom is breached and they have your customer data, that is your breach to report. Using large vendors does not transfer regulatory liability — you remain the Data Fiduciary or Covered Entity responsible for that data.
- How to fix it:
- Create a vendor inventory — every third party that touches your systems or data
- Classify vendors by data access level (high/medium/low risk)
- Obtain DPAs/BAAs from all vendors handling personal data
- Conduct annual reviews of critical vendor security posture
- Verify large vendors' security certifications (AWS SOC 2 report, Google CAIQ) annually
Failure 8: No Audit Trail or Logging
What the auditor asks: "Can you demonstrate audit logging for access to systems containing customer data? How long are logs retained?"
What most startups provide: "We have CloudWatch logs" — with no evidence that anyone monitors them or that alerts are configured.
Why this fails: Audit logs are the evidence layer of your security programme. Without logs, you cannot detect a breach in progress, cannot investigate an incident after the fact, and cannot demonstrate to an auditor that you monitor for unauthorised access.
- How to fix it:
- Enable detailed logging on all systems containing personal or sensitive data
- Configure alerts for suspicious access patterns (off-hours access, bulk data downloads, failed authentication attempts)
- Retain logs for at least 12 months (some frameworks require 7 years)
- Conduct monthly log reviews — automated SIEM tools make this practical
- Document your logging standards and retention policies
The Common Thread
Every failure on this list shares one characteristic: it is not a technical problem, it is a documentation and process problem. The technical controls often exist in some form. What fails the audit is the inability to demonstrate them.
Auditors are not just asking "are you secure?" They are asking "can you prove you are managing security systematically?" The proof is in the documentation, the records, and the evidence trail.
The investment to build a genuinely audit-ready security programme is modest relative to the enterprise contracts it unlocks. The cost of failing a security audit is the contract itself.
Written by Namita Kumari | Security Awareness Specialist at CyberSek
CyberSek provides both the security awareness training your audit requires and the VAPT assessments that close the gaps. Talk to us before your next enterprise deal enters procurement.