Dhaka Fintech Achieves PCI DSS Compliance in 90 Days for Series A

A Dhaka-based payments startup had received a Series A term sheet conditional on obtaining PCI DSS compliance. The lead investor — a Singapore-based fintech fund — required a valid AOC (Attestation of Compliance) before funds would transfer. The startup's legal and finance teams had 90 days from term sheet to funding close.

The startup processed card transactions on behalf of e-commerce merchants — a classic SAQ D (merchant) scope involving stored cardholder data. Neither the founders nor the small engineering team of eight had prior PCI DSS experience. The CTO had implemented what he believed were reasonable security controls, but had no framework to validate whether those controls met the specific requirements of PCI DSS v4.0.1.

The commercial pressure was significant. The Series A represented the company's primary growth capital. Two previous investor conversations had stalled at the due diligence stage when PCI DSS compliance could not be demonstrated. The current term sheet was the first to reach signed intent, and the 90-day window was fixed by the investor's fund deployment cycle — there was no extension available.

The startup's AWS infrastructure was reasonably well-architected — a small engineering team had made sensible technology choices. But sensible architecture is not the same as documented, assessed, and certified compliance. The gap between the startup's actual security posture and a formal SAQ D assessment readiness needed to be identified and closed in under 13 weeks.

• Series A term sheet conditional on valid PCI DSS AOC
• 90-day fixed window from term sheet to funding close
• SAQ D (merchant) scope — stored cardholder data
• No prior PCI DSS experience on the founding team
• USD 4.2M funding dependent on compliance milestone

CardIntel's scoping phase identified 12 specific control gaps that needed remediation before the formal SAQ D assessment could proceed. The gaps ranged from missing documentation (policies and procedures that existed in practice but were not formally documented) to technical implementations that needed configuration changes.

The most critical remediation was encryption at rest for stored cardholder data (PCI DSS Requirement 3). The startup's database contained cardholder data that was encrypted in transit but stored with application-level encryption using a key management approach that did not meet PCI DSS requirements. EIC's engineers worked with the startup's CTO to implement AWS KMS-based encryption with proper key rotation policies — a change that required database migration planning and careful execution to avoid service disruption.

Multi-factor authentication for administrative access (Requirement 8) was the second priority. The startup used password-only SSH access to production servers and single-factor authentication for the AWS console. EIC recommended and the team implemented hardware token MFA for AWS root and IAM accounts, and certificate-based SSH authentication for production server access — eliminating password-based administrative access entirely.

The logging and monitoring gap (Requirement 10) was addressed by configuring AWS CloudTrail and CloudWatch with alerting rules that met PCI DSS's specific log retention and review requirements. The vulnerability scanning programme (Requirement 11.3) was established with a quarterly ASV scanning schedule and the first passing scan completed within the engagement timeline.