A.8.26 Application security requirements: evidence and cost

A.8.26 application security requirements: what the control asks before code is written or bought

If your team is building or buying an application that an auditor will test under ISO 27001, the control to plan for first is A.8.26 Application security requirements. In plain terms, it asks that information security requirements are identified, specified and approved before an application is developed or acquired. That covers applications offered over public networks and the services that process transactions, such as payment flows, account changes and data submissions. The point is that security is decided while the design is still open, not discovered in a penetration test the week before launch. The control merges two controls from the 2013 edition, A.14.1.2 (securing application services on public networks) and A.14.1.3 (protecting application services transactions), so an assessor will look for both concerns in one set of requirements.

The risk A.8.26 addresses is that an application reaches production without anyone having defined what "secure" means for it. This is hard in practice for predictable reasons. Product owners write functional requirements and security requirements arrive later, if at all. Developers fill the gap with their own judgment, which varies from team to team. Vendors sold as turnkey products are accepted on a feature list with no security acceptance criteria. Requirements written after launch become backlog items that compete with features and quietly slip. Start with a short, approved requirements baseline for each application: which data it handles, who may access what (for example, a documented role model enforced by the application), how sessions and transactions must be protected in transit, how input is validated, and what logging must capture. Record who approved it and when, because that approval is the evidence the assessor will ask for.

For bought software, the same baseline becomes part of procurement. Ask the vendor to state its security requirements and how it meets them, and set those requirements into the contract or acceptance criteria before purchase, not after go-live. For self-hosted open-source platforms, the organization still has to decide the requirements, and the implementation partner can then configure and test the platform against them. Confirm with your certification body which evidence it expects for your scope, since the wording of the Annex A control and the depth of evidence required can differ between assessors. Keep the approved requirements under version control so changes are traceable.

Which applications, data and suppliers fall under A.8.26

A.8.26 applies wherever the organization builds or acquires an application that handles information, and the scope is set by how the application is used rather than by its label. The cards below cover the decisions that most change the requirements work, from internal tools to vendor software and outsourced builds. Each one should end with a written list of requirements that someone has approved.

Internal business applications

Internal tools such as HR systems, finance workflows and reporting dashboards still process sensitive information, so A.8.26 applies even when no customer ever logs in. Start with an inventory of which internal applications hold personal, financial or confidential data and who can reach them. For each one, record the access rules, the data it exposes and the approval point where those requirements were accepted. Confirm that internal applications are not excluded from the inventory simply because they sit behind the corporate network.

Customer-facing applications on public networks

Applications offered over public networks carry the most exposure, because the requirements must cover authentication, session handling, input validation and protection of data in transit. Specify these requirements before build or purchase, and confirm that they address the paths a customer uses to submit or retrieve information. Check that the approved requirements name the public endpoints, the data classes they carry and the protections expected on each path. Reviewers should be able to trace every public endpoint back to a written requirement.

Transaction services and data exchanges

Transaction services move information between systems, partners or customers, and the integrity of each message matters as much as its confidentiality. Requirements should state how transactions are authenticated, how they are protected against alteration or replay, and how failed or partial transactions are recorded. Confirm which transaction flows cross organizational boundaries, since these usually need agreed technical requirements with the other party. Document the flows in a form an assessor can follow from source to destination.

APIs and integration interfaces

APIs often expose the same data as a user interface but are easier to overlook during scoping, especially when they were added for partners or mobile clients. Inventory every API, including versions that are no longer advertised, and record the authorization model that governs each one. Requirements should cover how callers are identified, which scopes or roles they receive, and how the data returned is limited to what each caller needs. Confirm that retired endpoints are either removed or brought under the same requirements.

Vendor software and purchased applications

Software bought from vendors still needs documented information security requirements, because the organization cannot assume the product meets them. Put the requirements into the procurement file before selection, covering access control, encryption, logging, and how the vendor handles vulnerabilities. Confirm what the vendor's own evidence covers and where the organization must test the product in its own environment. A purchase that bypasses this step is still in scope for the control.

Outsourced builds and supplier-written code

When an outside team builds an application, the organization still owns the requirements, even if the supplier writes every line. The contract and statement of work should carry the security requirements, acceptance criteria and rights to review evidence from the supplier. Confirm who approves the requirements before development starts and who signs off on acceptance testing. This is the scope area where requirements most often exist only in a supplier's documents, so the organization should hold its own approved copy.

How an assessor tests A.8.26 requirements

This table walks through the steps an assessor usually takes to test A.8.26, with the evidence each step asks for and the findings that tend to come up. Read it as a sequence: sampling comes first, and the later rows check whether the requirements were approved, traced and reflected in the Statement of Applicability. The main takeaway is that a documented requirement only counts when it can be followed through to an approval and a test.

Assessor step	What the assessor does	Evidence requested	Common findings
Sample recent projects and purchases	Selects a sample of recent application builds, major upgrades and acquired applications, including internet-facing services	Project list, purchase records, release history and the organization's own sampling basis	Sample omits acquired or vendor-supplied applications, so purchases are never tested against A.8.26
Read the requirements documents	Checks that security requirements are written for each sampled system and cover access, authentication, data handling and cryptography	Requirements specifications, user stories with security criteria, or a requirements template	Requirements are generic policy text with no link to the specific application or its data
Check approval records	Confirms that a named owner with appropriate authority approved the requirements before development or purchase was committed	Sign-off records, change tickets, procurement approvals and dated versions of the requirements	Requirements are documented but never approved, or approved after build work had already started
Trace requirements to testing	Follows a sample of requirements into test cases, code review checklists or acceptance criteria and looks for evidence they were verified	Test plans, test results, security test reports and defects linked to requirements	Approved requirements are not traced to any test, so nothing shows they were met before release
Compare against the Statement of Applicability	Checks that the organization's justification for A.8.26 matches how requirements are actually set and approved in practice	Statement of Applicability entry, risk treatment decisions and the procedure that governs requirements	The control is marked as applicable but the procedure covers only some applications, or the entry cites a document that does not exist
Check public-facing transaction services	Reviews whether services offered over public networks have requirements for protecting information in transit and in transactions	Requirements for public services, TLS configuration records, transaction integrity checks and monitoring output	Public portals and APIs are missing from the requirements inventory, or protection relies on an unverified assumption
Review acquired applications	Checks that requirements for purchased or outsourced software were set before the contract was signed and verified at acceptance	Procurement security requirements, supplier evidence, contract clauses and acceptance test results	Security requirements appear only after go-live, or supplier evidence is accepted without checking it against the stated requirements

Writing security requirements into the build and buy cycle

This sequence turns A.8.26 from a policy statement into requirements that developers, buyers and testers can act on, with a record of who approved each one. Each step leaves a named artifact that an assessor can trace from the Annex A control to the test result.

Classify each application and purchase
Start with an inventory of every application the organization builds, modifies or acquires, including software-as-a-service products and applications offered over public networks. For each one, record the data it handles, whether it processes transactions, whether it is internet-facing, who owns it and whether it is built in house, customized or bought. The output is a classification register with one row per application, which sets how deep the requirements for the next steps need to go. Confirm the register with the asset owners, because an assessor will compare it against the asset inventory used under the organizational controls.
Define a requirement template
Create one reusable requirement template that the security, architecture and product owners agree on. It should cover four areas: access (authentication, authorization and least privilege for users and administrators), cryptography for public network and transaction traffic (encryption in transit, certificate handling and the approved algorithms defined under A.8.24), logging (which security events are recorded and where they go) and secure configuration (hardening baseline and default settings). Each classification tier then selects the template sections that apply. The output is an approved template and a tier-to-requirements mapping that the team can point to when a requirement is questioned.
Specify requirements for each application
For each application in the register, the product owner and security lead complete the template for that system and write the specific requirements in testable language, such as which roles may approve a transaction or which protocols the public endpoint must refuse. Requirements that cannot be tested should be rewritten until they can. For acquired products, the same requirements are sent to the vendor as part of the procurement file. The output is a signed requirements specification per application, with a version number and the date it was last reviewed.
Obtain named approval before build or purchase
A named owner approves each requirements specification before development starts or a purchase is signed. Approval should come from the business owner who accepts the residual risk and from security, with the approvers' names, roles and dates recorded. Where a requirement is waived, the waiver needs its own justification and a risk acceptance. The output is a signed approval record for each specification, stored where the change and procurement records are kept, so an assessor can see that requirements were approved before the system went live.
Link requirements to the security test plan
Map each approved requirement to a test case in the test plan under A.8.29, so that every requirement has at least one defined way to verify it. Examples include automated scans in the build pipeline, manual review of authorization logic, and acceptance tests for encryption on public endpoints. Open-source tools such as Semgrep can run in CI/CD pipelines for code-level checks, and GitLab protected branches can enforce that changes are reviewed before merge. The output is a traceability matrix that links each requirement to its test, its tool or manual method, and the latest result. Confirm the matrix with the testers, since it is only useful if the tests really check the stated requirements.
Write requirements into supplier contracts
For applications built or supported by external developers or vendors, carry the approved requirements into contracts, statements of work and service terms under A.8.30. Contracts should state the security requirements, the evidence the supplier must provide, such as test results or configuration records, acceptance criteria, and the organization's right to audit. Acquired software should be evaluated against the same specification before purchase. The output is a contract or order form that references the signed specification by version, plus a supplier evidence checklist that the acceptance team uses at delivery. Ask legal and procurement to confirm that the clauses survive renewal.
Keep the requirements current
Requirements change when applications change, when new threats appear and when vendors release new versions. Set a trigger for review, such as a major release, a change in data classification or a new public endpoint, and re-run the approval and test mapping when it fires. Vulnerability tools such as Wazuh or Fleet can flag software that falls below the expected baseline, which can prompt a review. The output is a change log for each specification and an updated traceability matrix, which together show the requirements stayed connected to the system over time. Ask an independent assessor which review triggers they expect to see documented.

Evidence that passes an A.8.26 audit and how to keep it current

An assessor testing A.8.26 looks for a traceable chain: the security requirements were identified for each application, approved by a named owner, carried into design and tests, and written into supplier contracts where others build or host the code. The cards below cover each artifact and the triggers that keep it accurate between audits.

Approved requirements per application

Keep one security requirements record for each application in scope, covering who uses it, what data it handles, whether it is reachable over public networks, and which transactions it processes. An assessor will pick a system from your asset inventory and ask for this record first. Check that the record names the application version it describes and that it reflects the current architecture, not the design from launch.

Requirement templates

Standard templates ensure every application gets the same baseline questions, such as authentication, session handling, input validation, encryption in transit, logging and access enforcement. Templates let teams show consistent scoping rather than ad hoc judgment. Confirm that each template version is dated, owned, and linked to the policy it implements, and that teams can record justified exceptions.

Approval records with dates and owners

An approval is only evidence if it shows who approved the requirements, when, and on what basis. Record the approver's role, the approval date, the application version and any conditions attached. Approvals should come from people with authority over the risk, such as the product owner together with security, and should be stored where they cannot be quietly edited after the fact.

Traceability from requirements to tests

Map each approved requirement to the design decision, the automated check, the manual test and the acceptance result that verifies it. Source code scanning and branch protection records can show that checks ran on each change. For example, a requirement for input validation on a public API should trace to a scanner rule, a penetration test finding or a documented acceptance test. Gaps in this chain are the most common reason assessors raise questions.

Supplier contract clauses

When a supplier builds, hosts or changes an application, the contract should carry the security requirements, acceptance criteria, evidence the supplier must deliver and rights to audit. Check that clauses name the applications and versions covered and that acceptance testing happens before go-live. Contracts signed before a requirement was approved often lack these terms, so review existing agreements at each renewal.

Review triggers between audits

Requirements decay when applications change without review. Set explicit triggers: a new public interface or API, a change in authentication or data classification, a new payment or transaction flow, a major release, a new third-party component or a finding from testing or incidents. Each trigger should create a dated review entry. Confirm with your certification body how they expect the review cycle to be shown across the three-year certification cycle.

Self-hosted open-source tools that produce A.8.26 evidence

A.8.26 asks for security requirements to be set and approved before applications are built or bought, and then kept in force. The tools below help produce records of how code changes are approved, how it is tested against security rules, and how deployed software is checked for known vulnerabilities. Each one covers a different part of that chain, and none of them proves on its own that the requirements were right.

Protected branches in GitLab

GitLab Community Edition (MIT) protected branches let maintainers restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. The settings and merge request history give an assessor evidence that approved requirements reach production through reviewed changes. The settings do not show that reviewers checked security requirements. Confirm the protection rules on each release branch, and record who may change those rules.

Security rule scanning with Semgrep

Semgrep Community Edition (LGPL-2.1-only) scans code with community or custom rules and can run in CI/CD pipelines to scan repositories continuously. Pipeline logs and results show that code was checked against defined security rules before merge. The scan does not prove that the rules cover the requirements you approved, and it does not test runtime behavior. Confirm current language coverage for your stack in your own environment, since the supported list changes, and document which rule sets you chose and why.

Vulnerability detection with Wazuh

Wazuh vulnerability detection correlates the software inventory from each agent with the Wazuh CTI repository or a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications of monitored endpoints. Its findings give evidence that deployed software is checked against known vulnerabilities over time. It does not show that the application itself meets its security requirements, and it covers only hosts where agents are installed. Confirm agent coverage and whether your environment needs the offline copy.

Software inventory checks with Fleet

Fleet (MIT) detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its reports help show which applications on managed hosts carry known vulnerabilities and how that exposure was tracked. Fleet does not assess custom application code or confirm that requirements were approved. Confirm which feeds apply to your operating systems and how often the data refreshes in your deployment.

Licence terms for open-source tools

GitLab Community Edition is MIT licensed, Semgrep Community Edition is LGPL-2.1-only, Wazuh is GPL-2.0-only and Fleet is MIT. The licence affects how you may modify, distribute or bundle each tool, which matters when you customize pipelines or ship internal changes. Record the licence and version of every tool in your asset inventory, and have legal review any modification before it reaches customers. Licence obligations do not change the evidence each tool produces.

What meeting A.8.26 costs in money and effort

This table breaks down the cost and effort components of meeting A.8.26 Application security requirements, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No price figures are given because none are supplied for this topic, so use the table to build a written scope and request a quote that itemizes each line.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Requirement writing and approval	Internal product owners, security lead and approvers; a consultant if drafted externally	One-time to set up, recurring when reviewed	Number of application types, public exposure, and how many approvers sign off on each requirement
Tooling for code and pipeline checks	Open-source tools such as GitLab Community Edition, Semgrep Community Edition and Wazuh carry their own license terms; setup and hosting are paid as services or internal time	One-time setup, recurring hosting and upkeep	Number of repositories, pipeline runners, and whether tools are self-hosted or run as managed services
Engineering time to trace requirements to tests	Developers and QA engineers mapping each requirement to a test, pipeline job or review step	Mostly one-time per application, recurring for new features	Number of requirements per application, existing test coverage, and whether traceability is kept in a tool or a spreadsheet
Supplier contract review	Legal, procurement and security staff reviewing security terms in vendor and third-party development contracts	One-time per contract, recurring at renewal	Number of outsourced developers or software suppliers, and whether standard security schedules already exist
External security testing	Independent testing firm or internal team, paid per engagement or retainer	Recurring, usually tied to releases or major changes	Application scope, number of public interfaces, and frequency of releases that need acceptance testing
Auditor sampling and evidence review	Certification body or auditor, plus internal staff preparing the evidence pack	Recurring at each audit cycle	Number of applications sampled, quality of traceable records, and how many nonconformities need follow-up

Who does what: your team, an implementation partner and the auditor

Your organization owns A.8.26. The requirement is yours to identify, specify and approve, and no partner or auditor can make that decision for you. Your security, product and application owners decide which information security requirements apply to each application, including applications offered over public networks and applications that carry transactions. They also accept residual risk when a requirement cannot be met, and they sign off on acquired software against those requirements.

Requirement ownership: Maintain a documented set of security requirements for each application class, covering authentication, authorization, input handling, encryption in transit and transaction integrity.
Approvals: Record who approved each requirement, when, and against which version of the application, so the approval can be sampled later.
Risk decisions: Decide and document any accepted deviation, with an owner and a review date.
Acquired software: Write the requirements into procurement and check the supplier's evidence against them before go-live.
Internal competence: Assign named owners who can explain the requirements to developers and to the auditor.

Before engaging any partner, confirm that your own owners can name each requirement, the person who approved it, and the evidence that shows it was met.

Where organizations fall short on application security requirements

A.8.26 is tested by asking whether security requirements were set, approved and carried through to delivery. The gaps below recur across organizations, and each one breaks the chain from requirement to approval to test evidence. Check each area against your own development and procurement records before an assessor does.

Requirements only for new builds

Teams often write security requirements when a project starts, then skip them when they buy a SaaS product, adopt a vendor library or accept a platform upgrade. The same information risk exists in those acquisitions, so A.8.26 expects requirements there too. Fix this by adding a short security requirements section to the purchase request and change templates, covering authentication, encryption in transit, data location and logging. Check a sample of recent purchases for a completed section.

Developers approving their own requirements

When the engineer who wrote a requirement is also the person who signs it off, nobody independent has checked that it reflects the information's sensitivity or the organization's policy. An assessor will ask who approved each requirement and whether that person had the authority to accept the risk. Assign approval to a security or risk owner, record the approver's name and date, and keep the record with the requirement set.

Requirements not linked to tests

A requirement such as "sessions must expire after inactivity" has little value unless a test confirms it. Many teams keep requirements in a document and run tests from a separate list, so nothing shows that each requirement was verified before release. Map every requirement to at least one automated or manual test and store the results with the release. Static analysis in CI, such as Semgrep Community Edition, can cover code-level requirements, though it will not cover every requirement on its own.

Unprotected branches allow unreviewed code

If anyone with write access can push directly to the main branch, a requirement can be dropped from a release without any approval record. Assessors look for the technical enforcement of the approval step, not only a written procedure. Restrict push and merge rights on protected branches, disable force pushes unless explicitly approved, and require review before merge. In GitLab Community Edition, protected branches provide these settings. Confirm the configuration in the repository itself, not in the policy.

Public services without transaction protection

Public-facing applications that process payments, forms or account changes often launch with encryption of the site and no written rule for protecting each transaction. A.8.26 specifically covers application services on public networks and transaction services, so the requirement should name what must be protected, such as integrity of the transaction, replay resistance and confirmation of the user's action. Write these rules before launch, test them against the live endpoints, and record the owner who accepted any residual risk.

Requirements not reviewed after change

A requirement approved two years ago may no longer match a new data type, a new integration or a new regulation. Organizations rarely schedule a review, so the requirement set drifts away from the system it describes. Set a review trigger for each significant change to the application, data flow or supplier, and a periodic review date for the whole set. Keep the dated review records, since they show the requirements are maintained and not just created once.

Questions buyers ask about A.8.26 cost, effort and outside help

How much effort does A.8.26 take for a small team?

The effort depends mostly on how many applications the organization builds or buys and how many of them face public networks or process transactions. No effort figure is supplied for this control, so treat any number you hear as a question to ask the vendor or partner, not a benchmark. For a small team with one customer-facing application, the work is usually a short set of written requirements, a review of how the application handles authentication, encryption in transit and access rules, and a record that someone with authority approved them. The work is front-loaded, then recurs when the application changes materially. Ask any partner to break its estimate into requirement writing, technical review, remediation and evidence collection, so you can see which part your team carries.

Can a small team handle A.8.26 in-house?

Yes, a small team can usually write and approve the requirements itself, provided someone understands both the application and the security concerns behind it. The control asks that requirements are identified, specified and approved, so the core deliverables are documents and decisions, not new tooling. The harder part is verifying that the application meets those requirements, which often needs someone who can read code, review configuration and interpret test results. If that skill is missing, the team can keep ownership of the requirements and approvals while buying technical review for the verification. The organization stays accountable for the control either way.

What does the team need to provide to an implementation partner?

A partner can only prepare evidence for systems it can see, so the team should be ready to provide a clear inventory of the applications in scope, their architecture and data flows, the hosting and network setup, and any existing requirement or security documents. The team should also name the people who can approve requirements and decide on risk acceptance. Access matters too: the partner will need read access to source repositories, CI/CD pipelines and environments under an agreed access process. Ask the partner to list these inputs in the written scope before work begins, so gaps show up early and do not delay the engagement.

How long does preparation for A.8.26 take?

The duration depends on scope: the number of applications, how many are internet-facing, how mature the existing development practices are, and how much remediation the review uncovers. No duration figure is supplied for this control, so do not accept a generic timeline without seeing the assumptions behind it. A fixed-scope engagement with written deliverables and dates is the right place to agree a timeline. Ask for the milestones, what the team must do at each one, and what would move the dates. Remediation work that belongs to your developers often takes longer than the documentation itself.

Do open-source tools remove license spend for A.8.26?

Open-source tools can reduce license spend, but they do not remove all cost. Source code scanning and repository controls can run on open-source components, for example Semgrep Community Edition for static analysis in CI/CD pipelines and GitLab Community Edition for protected branches, each under its own license terms. Your team still pays for hosting, administration, rule tuning, triage of findings and the time to configure approvals and keep evidence. Confirm the license terms and feature coverage of each edition with the vendor before relying on them, since community editions can differ from commercial tiers.

Can a consultant or partner certify A.8.26 for us?

No. A consultant or implementation partner can help you design requirements, prepare systems and assemble evidence, but it cannot certify the control. Certification of an ISO/IEC 27001 management system is issued by an accredited certification body after an independent audit. ISO itself does not certify organizations, and the certification body must be independent of the firm that helped you prepare. Ask any partner to state in writing what it will and will not do, and confirm the certification body's accreditation through the IAF CertSearch database.

What does DeployOpen do for A.8.26?

DeployOpen prepares the systems and evidence for this control in a self-hosted, open-source environment that the client runs in its own cloud accounts, data centers or air-gapped networks. Work is typically fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts, and a quote follows from that written scope. DeployOpen can help with configuring repository protections, pipeline scanning and requirement traceability, and it can run security testing of applications. DeployOpen does not issue audit reports or certifications, and the client keeps ownership of its requirements and approvals. Ask for the written scope to see exactly which parts are included.

How DeployOpen scopes, implements and prepares A.8.26 evidence

DeployOpen works on A.8.26 by helping the organization define its application security requirements, build the systems that enforce them, and assemble the records an assessor will ask for. The organization keeps ownership of its controls, and an independent auditor or certification body makes the certification decision.

How we scope

Agree in writing which applications, services and acquisition or development projects fall under the A.8.26 requirements.
Document the security requirements each in-scope application must meet, including access, encryption and transaction integrity for public-facing services.
Confirm who in the organization approves the requirements and how that approval will be recorded before work starts.

How we build

Configure self-hosted GitLab Community Edition protected branches so that only defined roles can push or merge and force pushes stay disabled.
Integrate Semgrep Community Edition into CI/CD pipelines so repositories are scanned against the agreed secure coding rules on every change.
Set up Wazuh or Fleet to inventory software on in-scope endpoints and match it against known vulnerabilities, with results routed to the owners who approve requirements.

How we hand over

Deliver the written application security requirements, approval records and the configuration of each tool, so the organization can show how requirements were specified and approved.
Export scan results, branch protection settings and review records in a form an assessor can sample, with clear notes on what each record proves.
Document the operating procedure so the organization's own staff can repeat the reviews and keep the evidence current after the engagement ends.

How we support

Ongoing support, upgrades and continuous security testing are available as a retainer after the initial fixed-scope engagement.
Agree the support boundaries in writing, including who updates rules, reviews findings and maintains the self-hosted tooling.
Confirm with your auditor which evidence they expect for A.8.26 before the engagement, since DeployOpen prepares evidence but does not issue reports or certificates.