IT project security audit: evidence for acceptance and handover

An audit of cybersecurity and information-system construction can mean several different things. A public-sector auditor may examine authority, procurement, spending, asset registration, contract performance, or whether the project achieved its intended benefit. A security team may instead need to determine whether the delivered system implements promised controls and can be operated safely after the supplier leaves. Those questions can support one another, but they do not produce interchangeable conclusions.

For a buyer commissioning or accepting an IT project, the useful security question is narrower and more operational: can every material security promise be traced to the exact delivered assets, shown to work under agreed conditions, assigned to an owner, and either accepted or recorded as an explicit gap? A polished policy pack or a successful vulnerability scan answers only part of that question.

This article presents a buyer-side method for that chain. It is practical guidance, not a universal statutory checklist. Applicable procurement, accounting, sector, data-protection, and certification duties still need advice from the buyer's responsible legal, financial, and compliance functions.

Define which audit conclusion is being requested

Start by writing the decision that the review must support. “Pass the audit” is too vague. The approval body may be deciding whether to release a payment, recognize an asset, authorize production use, accept a residual risk, or close a supplier contract. Each decision needs different evidence and a different accountable signer.

A financial or procurement audit can identify an unapproved purchase, a conflict between tender documents and the signed contract, an unregistered software asset, or payment before an agreed milestone. A performance audit can ask whether the system is used and whether it delivered the intended public or business outcome. A legal or regulatory review interprets duties and formal approvals. A contracted technical security assessment evaluates observable design and implementation behavior within a defined scope. Finding an exploitable authorization flaw does not by itself establish a procurement-law breach; conversely, a contract discrepancy does not prove an exploitable vulnerability.

Keep these workstreams connected through common identifiers, but issue conclusions in their own terms. The broader information-system security audit overview is useful context for control domains; project acceptance requires the additional trace from a promise to the delivered and operated system.

Build one trace from promise to decision

The core artifact is an acceptance traceability matrix. One row represents one testable security obligation or one approved exception. It should begin with the authoritative requirement: tender, statement of work, contract, approved architecture, threat model, policy, or change order. It should end with a named decision owner and status. Between them, it should identify what was delivered, what build is running, how the control was observed, and who will operate it.

Do not turn a broad framework into hundreds of copied rows without deciding applicability. For a web application, a recognized verification catalogue can help write precise control requirements, but the contract should freeze the catalogue version and requirement identifiers. Requirements change between versions. “Compliant with best practices” cannot tell a tester what to verify or a buyer what to reject.

This matrix complements a general audit plan. It also avoids the common failure where teams collect many documents but cannot show that any of them describe the production candidate. Guidance for managing an information-security audit can organize stakeholders and findings; the matrix binds that governance to a particular release and handover.

1. PromiseFreeze the source, version, applicability and accountable owner
2. IdentifyReconcile the promised control to a delivered asset and deployed build
3. DemonstrateObserve allowed, denied, failure and recovery behavior in an authorized environment
4. TransferProve agreed customer control of administration, evidence, support and recovery
5. DecideAccept, conditionally accept, reject or defer each remaining gap with authority

Reconcile the delivered system before judging controls

Security testing against the wrong build creates precise but irrelevant evidence. Before reviewing settings or attempting any test, reconcile the delivery package with the acceptance environment. Record source revision or vendor release, build pipeline run, binary or container identifiers, infrastructure and configuration versions, database migration state, enabled modules, third-party services, tenancy, and the time window in which the evidence was collected.

The goal is not to demand source code or every low-level development artifact from every supplier. Assurance should be proportionate to criticality, exposure, data, and the buyer's ability to use the evidence. A mature supplier may provide high-level secure-development attestations and trace them internally to lower-level records. Release-specific evidence becomes necessary when acceptance must establish the behavior of the actual build, when a material claim is disputed, or when the risk justifies deeper inspection.

Reconcile scope completeness as well as versions. Compare the contract bill of materials, architecture, cloud accounts, domains, APIs, administrative interfaces, mobile clients, jobs, integrations, and support connections with observation from the environment. Record exclusions rather than silently treating them as passed. If the system has changed after a report was issued, state whether the change invalidates only one test, a whole control family, or the acceptance conclusion.

Replace document-only review with observed demonstrations

Documents explain intended control; observed tests show some behavior under stated conditions. Both are needed. A role matrix may show who should administer the system, while a controlled demonstration shows whether a customer administrator can actually perform the task and whether another role is denied. A backup policy states frequency and retention; a restore demonstration shows that a selected backup can produce a usable service. A logging specification lists events; a generated event and export show that the buyer can retrieve attributable evidence.

Use positive and negative controls. For privileged access, demonstrate an approved administrator action, a forbidden action by a lower role, revocation, and the resulting audit trail. For backups, show selection, integrity checks, restore prerequisites, encryption-key access, and a business-level validation after recovery. For logging, generate a known event, follow it from source to storage, verify time and actor fields, test export, and establish what happens if the central collector is unavailable. For supplier support, activate an authorized session, observe approval and recording, then close it and verify that access no longer works.

A demonstration does not prove every possible state. Record environment, prerequisites, tester identity, data used, expected result, actual result, timestamps, evidence location, cleanup, and limitation. This makes “works” a bounded claim. The same principle appears in network-segmentation acceptance testing: a diagram is a hypothesis until allowed and denied paths are observed from representative positions.

Prove operational ownership, not just successful delivery

A system may pass functional acceptance while remaining impossible for the buyer to administer safely. Within the agreed service model and ownership boundaries, handover must establish operational control over identities, privileged roles, domains, certificates, keys, backups, monitoring, source or escrow arrangements where contracted, deployment tooling, licenses, and vendor portals. Inventory entries should identify owner, environment, version, support status, data class, dependencies, and retirement path.

The required control model depends on the service. For a customer-hosted or bespoke system, handover may include deployment assets, customer-held administrative roles, configuration, recovery material, and contracted source or escrow rights. For managed SaaS, the customer normally should not receive provider root accounts, proprietary source code, or provider signing keys. Acceptance should instead prove the customer's agreed administrative powers, data and log export, identity integration, support and recovery commitments, exit mechanism, and accountable service ownership. Technical checks must stay within the shared-responsibility model and the provider's authorized testing policy.

The buyer should demonstrate routine customer-administration tasks using buyer-controlled identities. For customer-hosted or custom systems where the agreement assigns top-level administration to the buyer, the supplier must not remain its sole holder. If continuing support requires remote access, define who authorizes each session, how strong authentication works, where actions are logged, which networks and hours are allowed, and how access is revoked. Emergency access needs custody and exercise appropriate to the service model. Shared credentials delivered in a sealed envelope are not a sustainable ownership model.

Support dependency is part of security. Record which patches, signatures, repositories, subscription features, certificate renewals, managed keys, or recovery actions require an active paid plan. State support life, end-of-life notice, response levels, vulnerability intake, update authenticity, subcontractor dependencies, and alternatives if the supplier stops serving the product. A control that works only while an undisclosed license remains active is not fully described.

Contract exit deserves acceptance evidence too. Establish how the buyer obtains or transfers customer-owned or contractually exportable data, configuration, logs, domains, keys, and service knowledge; how supplier copies and delegated accounts are removed where agreed; and how completion will be verified. This does not require transfer of provider platform signing keys or other provider-root assets. The third-party risk assessment guide helps evaluate the supplier relationship over time, while this project matrix attaches those questions to the delivered service and its exit path.

Separate discrepancies, weaknesses, and residual risk

Use finding types that direct the issue to the right authority. A contract discrepancy means the delivered item or evidence differs from the agreement. A technical weakness means an observable design or implementation condition could enable harm. An evidence gap means the claim could not be established with available, trustworthy material. An operational gap means ownership, monitoring, recovery, support, or exit is not ready. A legal, financial, or procurement concern should be referred to the competent reviewer rather than converted into an unsupported technical or legal conclusion.

The same fact can create several linked records. If, in a customer-hosted or custom system, the supplier holds the only top-level administrator account despite an agreement assigning that role to the buyer, the contract team may check the responsibility model; the security team may assess exposure and monitoring; operations may block handover until customer access and recovery are proven. Link the records, but do not collapse their conclusions.

For every unresolved item, name the authority that can accept it. Record affected asset and release, business consequence, preconditions, current mitigation, compensating control, due date, support dependency, retest trigger, and expiry. “The project team accepts the risk” is insufficient if that team does not own the affected service, data, budget, or statutory duty. Conditional acceptance should state the permitted operating envelope and what event suspends it.

Risk acceptance allocates a recognized residual risk; it cannot cancel a mandatory legal, regulatory, procurement, or contractual obligation. Where the team is unsure whether an obligation is waivable, the issue remains open until the competent owner decides it.

Use independent penetration testing where it answers a defined claim

Independent penetration testing is useful when the buyer needs adversarial evidence about an exposed or high-impact technical boundary: for example, whether users can cross tenant or role boundaries, whether an administrative interface is reachable outside the intended path, whether support access can bypass customer approval, or whether segmentation blocks representative attack paths. It can also retest a material fix before final acceptance.

It should not be used as a generic substitute for asset reconciliation, legal interpretation, procurement review, secure-development assurance, backup restoration, operational training, or supplier-exit planning. A pentest samples an agreed environment during an agreed period. It does not certify the whole project, guarantee future security, or prove that every contractual promise has been delivered.

Pentest.red can perform an authorized technical penetration test over the systems and behaviors the parties place in scope. The resulting technical pentest report is not a Chinese statutory audit or certification conclusion and does not guarantee project acceptance. The scope planner helps record assets, releases, roles, exclusions, test accounts, evidence access, stop conditions, and retest needs before testing begins.

Commission an acceptance package that can survive handover

Ask for one coherent package rather than a folder of unrelated files. It should include the traceability matrix; reconciled asset and release manifest; architecture and data-flow baseline; access and responsibility matrix; control demonstration records; vulnerability and remediation register; backup and restore evidence; logging and export evidence; support, update, license, and end-of-life dependencies; customer runbooks; supplier-access closure evidence; and a signed residual-risk register.

Define evidence handling in advance. Sensitive configuration, logs, test data, credentials, and proprietary development records need controlled storage, retention, redaction, and access. The buyer should receive enough detail to reproduce the conclusion without acquiring low-level material it cannot safely protect or interpret. A useful finding names the exact affected asset and build, observation, preconditions, impact, evidence, recommended action, owner, and retest condition. A sample penetration-test report shows how reproducible technical evidence can be separated from impact and remediation; the project acceptance record must additionally link that finding to the contract, operational owner, and decision.

Acceptance is therefore a sequence of bounded decisions, not a security stamp. Freeze what was promised, identify what was delivered, observe what works, transfer the ability to operate and recover it, and place each remaining gap before the person authorized to accept it. That creates an auditable handover even when the answer is conditional, and it keeps technical testing honest about what it did and did not establish.