Software security: What should you ask first?
Consider a hypothetical customer-document portal: customers upload files, assigned staff process them, managers track progress and email notifications are sent.
The buyer need not inspect source code personally. They need to understand where records travel, which boundaries the supplier will verify and which responsibilities continue after handover.
To assess the security proposal, a business owner needs to understand where these records go, who may access them and what the supplier will demonstrate before launch. The questions below clarify scope and responsibility without requiring programming knowledge.
1. Which data does the system need to protect?
Look beyond the main screen at downloaded files, emails, exported reports and test data. Ask the supplier to trace a record through those locations and identify access at each step. Hiding information on the screen does not establish control of the other paths.
Establish when a record is no longer used, who decides retention or deletion and how exported copies are handled. Specific periods must follow confirmed business needs and requirements. A delete-record feature should not leave developers inventing the retention policy.
Then establish task-based access. Assigned staff may need a case’s files without a complete export; managers may need progress summaries without every attachment.
These are policies to confirm, not universal rules. Task-based boundaries reduce both excessive access and restrictions that drive staff to share files elsewhere.
Once you know who needs to view or process a record, agree permissions for individual actions, such as opening files, editing details or exporting a list. How to assign the right user permissions explains how to turn those business needs into specific access rules to discuss with the development team.
What responsibility remains when using an external service?
External services do not remove responsibility questions. Identify protection supplied by the service, configuration and permissions managed by implementers, and client approvals. Assign unresolved checks and evidence rather than assuming a major platform protects every part of the application.
2. How will the supplier verify security?
Different checks answer different questions: code review examines implementation, dependency checks identify known component issues, configuration review examines the environment, and misuse tests exercise enforced boundaries.
Few scanner findings cannot replace an activity that was never performed.
For example, use authorized test cases for two separate users. One must access their own record but be refused the other’s through both the screen and file path.
Verify applicable paths after permission revocation too. Tests need authorization and a suitable environment, not unapproved access to real customer records.
Beyond access tests, clarify how service credentials such as passwords and access keys are managed. They should not be mixed into broadly shared documents or source repositories. Agree appropriate ownership, rotation and revocation arrangements.
For web applications, a reference such as OWASP ASVS can support discussion of requirements and verification, with an appropriate scope selected. Reports should state the environment, coverage, findings and limitations. External specialist testing needs its own agreed scope, responsibilities and execution conditions.
The report should identify the system and version, exclusions, unresolved findings and who accepts remaining risk. Retest evidence should connect fixes to findings. A fixed status alone is insufficient if verification is missing or the release differs from the version assessed.
3. Who decides and responds when problems arise?
For a finding, assess impact and assign remediation, retesting and release conditions. Unresolved issues need an explicit mitigation or risk-acceptance decision. Recording a finding or seeing no visible error is not the same as resolving it.
Findings have different consequences. Unauthorized access to customer files needs a different assessment from a low-impact internal defect.
Technical staff should explain conditions, affected data and response options intelligibly so accountable owners can judge business risk. A severity label or score alone does not capture the entire context.
Before agreeing ongoing support, establish reporting contacts, included remediation, separately priced work and update-deployment authority.
Discuss missing time and service commitments rather than assume continuous availability and immediate fixes. This prevents responsibility gaps after acceptance.
Before launch, exercise a reporting route: intake, impact assessment, authority to restrict access and communication to affected stakeholders. Sensitive live data is unnecessary for that exercise. Verify that contacts and decision rights work before an actual incident forces the issue.
After launch, assign ownership for component-vulnerability notifications and update decisions. This involves both operations and the supplier’s support scope. Update the documentation when contacts, administrative accounts or reporting routes change.
Monitoring vulnerabilities and updating the system continue after handover. When agreeing support with the supplier, clarify which tasks the contract covers and which remain with your internal team. What does software maintenance actually cover? helps you review that scope before assigning responsibilities.
4. What should be agreed before development?
The discussion should produce a shared scope covering protected data, users, data paths and enforced boundaries. Give unresolved questions to owners and decision dates. Security requirements then become work the project can track.
The verification plan should identify coverage, timing, performers and required evidence. Independent testing also needs authorized scope and ownership of findings. Unresolved issues require mitigation, acceptance ownership and review conditions rather than merely being moved to another list.
Before handover, identify who will manage accounts, receive alerts, retain verification evidence and own unresolved issues. Acceptance of the software does not close those responsibilities if the receiving team cannot perform them.
To carry out those responsibilities, the incoming team needs instructions, access and the relevant verification records. Confirm that the team can use what it receives, rather than only counting the documents delivered. Software handover: What should you receive? explains how to check that the next team can take over before the project closes.
Discuss the intended use and information flows with Fenix to identify development requirements and areas needing additional expertise or verification.
