In many software projects, security is scheduled as a phase: a penetration test a few weeks before launch. By then the architecture is fixed, the data model has hardened, and every serious finding becomes expensive rework, or an “accepted” risk that nobody is comfortable signing.
Security by design moves those decisions to where they are cheapest: requirements, architecture and the daily engineering workflow. For leaders, the practical question is not how to become a security expert, but what to require from the partners who build their software, and how to tell whether they actually deliver it.
Make security a requirement, not a phase
Write security into the RFP and the contract with the same precision as functional scope. One practical way to do this is to reference an established baseline, such as a level of the OWASP Application Security Verification Standard (ASVS) appropriate to the system’s risk, and to require threat modeling during design: a structured review of what could go wrong, using a method such as STRIDE, updated whenever the architecture changes.
Ten things to require from your software partner
- Threat modeling for every major feature and architectural change, with documented mitigations.
- A secure development lifecycle: peer code review with security criteria, static analysis, dependency scanning and secret scanning built into the CI pipeline.
- Strong identity and access: single sign-on with OpenID Connect where possible, MFA for administrative access, least-privilege roles and secure session handling.
- Data protection: TLS for all traffic, encryption at rest with managed keys, field-level protection for highly sensitive data, and collecting only what the product genuinely needs.
- Secrets management: no credentials in source code, repositories or chat messages, but a dedicated secrets manager with rotation.
- Audit logging: security-relevant events recorded in tamper-evident logs, with defined retention and no sensitive personal data written to them.
- Environment separation: production data never copied into development or test environments without masking.
- Independent testing: a penetration test before go-live and after significant changes, with findings tracked to closure.
- Vulnerability management: a software bill of materials (SBOM) and agreed timelines for patching critical vulnerabilities.
- Incident response: named contacts, escalation paths, notification timelines and a rehearsed runbook.
Add one more clause to the contract: at handover, you receive the source code, infrastructure-as-code, documentation and all credentials, and the partner’s access to production is revoked or formally re-scoped.
Extend the requirements to third parties and AI features
Modern applications are assembled as much as they are written. Payment SDKs, analytics scripts, open-source libraries and AI model APIs all become part of your attack surface and your data flows, so the same discipline should apply to them.
- Third-party components: an approved list of SDKs and services, a review of the data each one receives, and license checks for open-source dependencies.
- AI features: clear rules on which data may be sent to external model providers, defenses against prompt injection, and human review for actions with financial or legal effect.
- Software supply chain: signed builds, protected branches and controlled access to the deployment pipeline, so that what reaches production is exactly what was reviewed.
The Saudi regulatory context
Organizations operating in the Kingdom should consult the relevant national frameworks early, while requirements are being written rather than after the system is built. These typically include the Personal Data Protection Law (PDPL) and its implementing regulations, overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA); the National Cybersecurity Authority’s Essential Cybersecurity Controls (ECC) and related frameworks such as the Cloud Cybersecurity Controls; and sector-specific requirements from regulators such as the Saudi Central Bank for financial institutions. A capable software partner should be able to translate these into concrete technical controls and verifiable evidence.
Questions to ask during vendor selection
- “Can you walk us through a redacted threat model from a previous engagement?”
- “How does a secret reach production, and who can read it?”
- “A critical vulnerability is announced in one of our dependencies on a Thursday evening. What happens next?”
- “Who on your team will have access to our production data, and how is that access logged and reviewed?”
- “What exactly do we receive at handover, and in what form?”
Good partners answer with specifics and artifacts. Vague reassurance is an answer in itself.
Red flags
- “We’ll take care of security at the end.”
- Shared administrator accounts, or credentials sent by email or chat.
- No separate staging environment, or production data used for testing.
- Reluctance to allow independent penetration testing.
- Unclear answers about where data is hosted and who can access it.
Security is a property of how software is built, not a feature added before launch.
What good looks like, day to day
In a healthy engagement, security appears in the definition of done for every feature, not in a separate report at the end. Pull requests show security checks passing, architecture decisions record their security trade-offs, and leadership receives evidence (scan results, test reports, access reviews) rather than assurances. That evidence is what allows a leader to sign off on a launch with confidence, and it is the standard AMA GROUP holds itself to in security engineering work.