Before Go-Live: What a Serious Security Review Should Cover

1. Define the launch boundary and assurance objective

Inventory what is actually going live: domains, applications, APIs, mobile builds, administrative surfaces, cloud accounts, identity providers, third-party services, data stores, deployment pipelines and support tools. Record which environments and versions can be tested, what is excluded, and who has authority to approve the scope. An assessment of a staging application says little about production if identity, configuration and integrations differ materially.

Set an assurance objective tied to risk. Examples include verifying that customer accounts cannot cross tenant boundaries, that privileged actions require strong authorization, or that sensitive information is protected across collection and export. Use applicable NCA, sector and organizational requirements as inputs, but translate them into testable system behavior and evidence. A control reference alone is not proof that the implementation works.[1][2]

• Exact assets, versions and environments
• Data classifications and critical journeys
• Threat actors and material abuse outcomes
• Named scope owner and launch decision authority

2. Model abuse paths before selecting tests

Threat modeling connects architecture to adversarial behavior. Map entry points, identities, trust boundaries, sensitive operations and dependencies. Ask what an anonymous user, ordinary account, compromised administrator, malicious partner or breached service could attempt. Prioritize paths that affect confidentiality, integrity, availability, financial value, safety or the organization’s ability to operate.

A concise model helps the team avoid a checklist that spends equal effort on unequal risks. It also exposes design questions that scanning cannot answer: whether one role should hold a permission, whether a support workflow can bypass normal approval, or whether a failed integration leaves a transaction in an unsafe state. Keep the model with the product and update it when architecture or trust changes.[4]

3. Verify identity, sessions and authorization

Identity failures create direct paths to consequential actions. Review registration, recovery, multifactor enforcement, session creation and revocation, device changes, support overrides and privileged access. Test rate limits and abuse resistance without risking real users. Confirm that sensitive transitions require recent or stronger authentication where appropriate and that secrets or tokens do not leak into URLs, logs or client storage.[3][1]

Authorization must be tested at the server boundary for every object and action, not inferred from hidden buttons. Build a role-and-resource matrix and attempt horizontal, vertical and cross-tenant access using representative accounts. Include exports, background jobs, bulk actions and administrative APIs. Record privileged activity in a form that supports investigation, while ensuring logs do not become another store of sensitive credentials or personal data.

4. Exercise application and API controls

Use manual testing and appropriate tools to evaluate validation, injection paths, file handling, business rules, concurrency, error behavior, browser controls and API abuse. Test the documented contract and what happens outside it: unexpected methods, duplicate submissions, oversized requests, stale versions and manipulated identifiers. Mobile clients must not be treated as trusted merely because they are distributed through an app store.[3]

Business-logic tests deserve explicit time because automated scanners rarely understand approval sequences, entitlements, promotional rules or operational constraints. Follow high-value workflows from beginning to end and attempt to skip, repeat, reorder or partially complete stages. Assess how downstream failures are reconciled. A technically valid request can still produce an unauthorized or financially harmful outcome.

• Input, output and file-processing boundaries
• Object, function and tenant authorization
• Business sequence and concurrency abuse
• Rate limits, resource exhaustion and error handling

5. Review dependencies and the delivery path

Production risk includes the software supply chain and the mechanism used to release it. Inventory direct and transitive components, remove unsupported packages, review material vulnerability exposure and preserve provenance for built artifacts. A dependency finding should be assessed in context: reachable behavior, deployed version, compensating controls and available remediation—not severity copied blindly from a feed.[4]

Inspect repository permissions, branch protection, CI identities, secret access, build isolation, artifact storage and deployment authorization. Confirm that the deployed artifact can be traced to reviewed source and that rollback does not reintroduce a known weakness. Rotate any credential exposed during development or testing. A secure application can be undermined by an uncontrolled pipeline that produces or deploys it.[1]

6. Validate platform, data and production configuration

Review network exposure, administrative endpoints, storage permissions, encryption configuration, secret management, backups, environment separation and cloud identity. Compare production settings with the intended architecture and remove development conveniences. Verify that diagnostic modes, sample accounts, default credentials, permissive cross-origin rules and unused services are not present in the release boundary.[1]

Trace sensitive and personal data through the deployed service. Confirm minimization, access, retention, export and deletion behavior with the responsible privacy and legal stakeholders. Test backup restoration and access rather than assuming that a successful backup job proves recoverability. Where Saudi personal-data requirements apply, the system design and operating procedures should provide evidence for the organization’s actual responsibilities.[5]

7. Prove detection and incident readiness

A launch review should test whether the organization can see and respond to meaningful misuse. Generate agreed security events in a controlled manner and confirm that logs contain the right identity, action, resource, time and outcome; that alerts reach an accountable team; and that responders can obtain context without accessing excessive sensitive data. Logging that exists but is not monitored does not provide the same assurance as an exercised response.[2]

Walk through account compromise, exposed credential, malicious upload, service outage and suspected data-access scenarios. Confirm contact paths, containment authority, evidence preservation, customer or regulatory escalation decisions and recovery steps. The purpose is not to predict every incident. It is to ensure that the first critical decisions are owned and executable when information is incomplete and time matters.

8. Turn findings into an owned launch decision

Report findings with evidence, affected assets, realistic abuse conditions, impact, reproducibility and remediation guidance. Separate confirmed vulnerabilities from hypotheses and tool failures. Agree severity using technical and business context, then assign an owner and due date. Retest material fixes in the release candidate; a ticket marked complete is not verification that the weakness is removed.

Define launch-blocking criteria before the review concludes. Any accepted residual risk should name the accountable authority, rationale, duration, compensating control and review date. Preserve the scope, evidence and decisions as a baseline for future releases. Security assurance is strongest when it becomes a repeatable part of product delivery and operations—not an exceptional gate negotiated under launch pressure.[4][3]