Safeguard 16.1 Secure application development process

What a secure application development process must cover under Safeguard 16.1

Safeguard 16.1 asks the enterprise to establish and maintain a documented process for building software securely. The process has to say how designs are checked against security standards, how developers write code, how they are trained, how vulnerabilities are handled, how third-party code is vetted and how applications are tested for security before release. It is the governing safeguard for Control 16, Application software security, and the other Control 16 safeguards hang off it. In CIS Controls v8.1 it sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1, it is classed under the Documentation asset class and the Govern security function. The risk it addresses is simple: software built without agreed design, coding, testing and vulnerability rules, where each team makes its own decisions and security defects reach production unnoticed.

Two patterns make this safeguard hard to meet. In the first, the process exists only in the heads of a few senior engineers or in habits passed between teams, so an assessor finds nothing written down to test. In the second, a document exists, often a wiki page or a policy written for an audit, but teams do not follow it and nobody checks. The assessment specification scores the Completeness of the process, meaning the share of the components that are included in it, and it fails the enterprise if no process exists at all. The practical starting point is to list every application team, every language and deployment path in use, and then decide which of those the written process must cover. Anything left out of the document is, for an assessor, outside the safeguard.

Before engaging an outside party, a CISO or compliance lead should confirm three things: who owns the document and when it was last reviewed, since the safeguard expects annual review or sooner after significant change, and whether the process names the tools and gates that enforce it. Ask whether a developer can point to the written rule for a design review, a code review, a dependency decision and a release gate. A process that cannot be traced to a repository setting, a pipeline job or a recorded approval is difficult to evidence. Your own assessors or CIS-aligned auditors will decide what counts as sufficient. An implementation partner can help draft the process, configure the repositories and pipelines that enforce it and collect the records, but the organization owns the process and its sign-off.

Which applications, teams and third parties a secure development process must reach

The scope statement is the first thing an assessor reads, because the Completeness metric measures the share of components included in the secure application development process. Each card below is a scoping decision that changes how much of the enterprise the process must cover, and what evidence the enterprise needs to show for it.

In-house, hosted and acquired software

Decide whether the process covers software your teams write, software your provider hosts for you, and commercial or open-source applications you buy or adopt. Each category needs a different proof point. In-house code needs design and review records, hosted services need your contractual and configuration responsibilities documented, and acquired software needs a way to request vendor security evidence. Confirm the inventory of applications is complete before you calculate Completeness, because an omitted application lowers the score without anyone noticing.

Development and platform teams

The process must reach every group that writes, builds, deploys or configures application code, including platform engineering teams that own pipelines, container images and infrastructure templates. Teams that only operate applications often make security-relevant changes to configuration and deployment logic. Write the team list into the scope statement and name the accountable owner for each group, so an assessor can trace each team to the process documents and training records.

Security and product teams

Security engineers who run reviews and product managers who set requirements both shape secure development outcomes. Product owners decide which features reach design review and how risks are accepted, so leaving them out of scope leaves a gap in the decision chain. Confirm that the documented process assigns responsibilities to security and product roles, and that the evidence includes sign-off on design standards and risk acceptance decisions.

Contractors and outsourced developers

Contractors and outsourced development firms often write production code under your name. Include them in the process scope, and make the secure development requirements part of their statements of work or contracts. Ask for evidence of their secure coding training, the review steps they follow, and how their code enters your repositories. Missing contractor work is one of the most common reasons a scope statement fails to match what the assessor finds in version control.

Third-party code and libraries

Open-source libraries, vendor SDKs and framework code run inside your applications, so they belong in the scope of the process even though your teams did not write them. Safeguard 16.1 covers third-party code security, which means the process must say how components are selected, reviewed and updated. Record which dependency sources are in scope and which pipeline stages check them, and link this card to the component inventory and selection safeguards in 16.4 and 16.5.

Scope statement and assessment baseline

Write one scope statement that lists the applications, teams, contractors and third-party code included, and the reasons for any exclusions. Safeguard 16.1 has no prerequisite safeguards in the CIS Controls Assessment Specification, so you can start here. Only IG2 and IG3 enterprises must meet this safeguard, while IG1 does not. Confirm your Implementation Group with your own risk and regulatory context before you commit resources, and review the scope statement annually or when significant enterprise changes occur.

How an assessor tests the secure development process and what fails it

This table compares what an assessor reviews, requests and commonly flags for Safeguard 16.1 across the document, its coverage and the applications it governs. Read each row as a question an assessor will ask, then check your own process against the evidence column before the assessment begins.

Test area	What the assessor checks	Where it usually fails
Existence of the process	Whether a documented secure application development process exists at all. The assessment specification gives a failing score when no such process is in place.	No written process, or practices that exist only as informal team habits with no document behind them.
Document review and annual update	Whether the document covers design standards, secure coding, developer training, vulnerability management, third-party code and application security testing, and whether it was reviewed within the last year or after significant enterprise change.	Document is out of date, predates a major platform or team change, or has no recorded review date or owner.
Completeness of coverage	The Completeness metric: the share of components, such as application teams, repositories and business units, that the process actually includes.	Some development teams, legacy applications or acquired products sit outside the process without a documented reason.
Third-party and open-source code	Whether the process states how third-party and open-source code is selected, reviewed and tested alongside in-house code.	Third-party code is named in policy but absent from the scope of reviews, testing or vulnerability handling.
Sampling of applications	Whether the assessor selects applications and checks that their design reviews, code reviews, training records and test results follow the written process. Sample size is set by the assessor, so confirm it in the engagement scope.	Applications in the sample show steps skipped, or evidence exists for some applications but not others.
Developer training linkage	Whether training requirements in the process match training records for the personnel who build and maintain the applications.	Process requires secure coding training that is not tracked, or new hires and contractors are not covered.
Scope of teams	Whether every team that builds or changes software, including outsourced developers, is named in or bound by the process.	Teams outside the defined scope, such as internal tools, scripts or contractor-built applications, have no equivalent process.

How to build the process in order and what each step produces

The sequence below turns Safeguard 16.1 from a policy statement into a documented, approved and reviewed process that an assessor can trace from scope to evidence.

Define scope and list components
Start by deciding which applications, repositories, pipelines, hosted services and acquired software the process covers, and which teams build, change or operate them. Record each in-scope component with its owner, its environment and whether it is developed in-house, hosted or acquired. The output is a scoped component list signed off by the application owner. Completeness is measured against this list, so an incomplete list weakens every later step. Confirm the list against the software inventory from Control 2 and the asset inventory from Control 1 so nothing falls out of scope.
Set secure design standards
Write the design standards that every in-scope application must meet, covering authentication, authorization, data handling, logging and the secure design principles addressed in Safeguard 16.10. Assign an owner who can approve exceptions and record why each exception was granted. The output is a standards document with version control, a named owner and an exception log. Architects and security staff usually draft it, and the development leads review it against real projects before it is approved.
Set secure coding practices
Define the coding rules developers follow for the languages and frameworks in the component list, such as input validation, output encoding, secrets handling and error messages. Tie each rule to a check that can be run, either a code review step or an automated scan that Safeguard 16.12 covers. The output is a coding practices standard per language or platform, linked from the repository templates so developers can find it during work. Keep the practices short enough that teams actually follow them.
Plan developer training
Identify which roles write, review, deploy or approve code and what secure coding training each role needs for its environment. Schedule training at least annually as Safeguard 16.9 requires, and record attendance per person. The output is a training plan and a training record that shows who completed which course and when. Link the plan to the coding practices from the previous step so the training teaches the rules the team is expected to follow.
Define vulnerability and third-party code rules
Document how vulnerabilities are received, rated and fixed, and how third-party and open-source components are selected and tracked. The rules should point to the detailed safeguards for intake (16.2), root cause analysis (16.3), component inventory (16.4), trusted components (16.5) and severity ratings (16.6). The output is a vulnerability management and third-party code section of the process document, with named owners and the ticketing system where findings are recorded. Assessors look for the link between these rules and real tickets, so keep the wording tied to your tools.
Define security testing procedures
Set out which security tests run at which stage of the life cycle: threat modeling before code is written (16.14), code-level static and dynamic checks (16.12), and application penetration testing (16.13). State what triggers each test, who performs it and what result blocks a release. The output is a testing procedure that names the tools, the stage and the pass or fail criteria for each test. Confirm which tests your environment can support before committing to them in the document.
Approve and publish the document
Circulate the complete process to the people named in it, collect comments, and resolve conflicts with delivery leads and security. Obtain approval from the executive or governance body that owns application risk, and record the approver, the date and the version number. The output is a signed-off version stored in a controlled location where the affected teams can find it. Publishing without approval makes the document a draft, so the approval record is itself evidence an assessor will ask for.
Run the annual review
CIS asks that the Safeguard 16.1 documentation be reviewed and updated annually, or sooner when significant enterprise changes could affect the process. Schedule the review, check each section against the current component list, training record and vulnerability data, and record what changed and why. The output is a dated review record and a new approved version when changes are made. Trigger an earlier review after mergers, new platforms, major architecture changes or a significant incident.

Which evidence artifacts show a secure application development process is in place

An assessor testing Safeguard 16.1 looks for a documented process and proof that it runs in practice. The artifacts below connect the written process to the people, code and tests that follow it, and no single item is sufficient on its own. Keep each one dated, versioned and linked to the process document it supports.

Approved process document and version history

This is the written secure application development process that covers design standards, coding practices, developer training, vulnerability management, third-party code and security testing. An assessor checks that it names the owner, the approver, the scope and the components it covers, and that every revision has a date and an approver. Keep the document in a system with full version history, so each change can be traced to a specific review. A process that exists only in a slide deck or a chat thread will not hold up.

Scope and component list

The scope record lists the applications, repositories, hosted services and acquired software the process covers. Safeguard 16.1 is scored on completeness, so an assessor compares this list against the systems actually in use. Review it when new applications launch, when acquisitions occur and when teams are reorganized. Record the date of each review and who confirmed the list, so a gap found later can be shown to be a known and tracked exception.

Design and coding standards

Design standards and secure coding practices set the expectations developers are measured against. An assessor looks for standards that address authentication, input handling, secrets, logging and dependency use, and for evidence that they were approved and communicated to the teams that build software. Link each standard to the version of the process document that adopted it. Retire outdated standards explicitly so teams are not following a superseded version.

Training completion records

Training records show that developers received the secure coding instruction the process calls for, and they should match the people who commit code. Assessors check completion dates, course content and whether new hires and contractors are included. Keep records by role and by person, and tie each course to the standards it teaches. Completion alone does not prove competence, so pair these records with code review findings that show the lessons are applied.

Repository and review settings

Repository configuration is the technical proof that the process is enforced rather than only written down. Export the protected branch rules, approval requirements and merge settings for each in-scope repository, and check that direct pushes to protected branches are blocked and force pushes are disabled unless explicitly allowed. Pair these settings with automated scan results in the pipeline. Capture the configuration on a schedule, because settings drift after administrators change them.

Security testing reports and follow-up

Static analysis, dependency scans and application penetration test reports show that security testing takes place as the process requires. An assessor expects each finding to have a status, an owner and a fix or accepted-risk decision, and expects the follow-up to be traceable to a commit or ticket. Use scan tooling such as Semgrep in CI/CD so results are generated continuously. Confirm with your own assessor which test types and frequency they expect for your environment.

Annual review and event-driven update records

Safeguard 16.1 documentation must be reviewed and updated annually, or sooner when significant enterprise changes could affect it. The review record should show the date, the reviewers, the changes made and the new document version. Also keep a log of trigger events such as a new platform, a major acquisition or a significant incident, with the update that followed. Link each review entry to the exact version it approved, so an assessor can confirm the cycle was maintained between audits.

What meeting Safeguard 16.1 costs in money and effort

This table lists each cost component of running a secure application development process under Safeguard 16.1, who is paid for it, whether it is one-time or recurring, and what moves it up or down. No price or duration is stated because none is supplied for this safeguard, so use the table to structure a quote request and compare written scopes.

Cost component	One-time or recurring	Who is paid or who carries the effort	What drives it up or down
Policy and standards authoring	One-time, then recurring review	Internal security and architecture staff, or a consultant drafting the process document	Number of development standards in scope and how many teams must adopt them. Reuse of existing secure coding standards lowers it.
Engineering time for gates and reviews	Recurring	Internal developers and security champions; a partner may configure the pipeline gates	Number of applications, release frequency and how many design reviews the process requires. Standard templates keep it down.
Tooling and licenses	Recurring where paid, one-time for setup	Software vendors for commercial tools. Self-hosted open-source tools carry no license fee, but hosting and setup are still paid	Number of languages and repositories scanned and whether commercial features are needed. Open-source tools remove license spend only.
Developer training	Recurring, at least annually for development personnel	Training providers or internal trainers, plus paid developer time away from delivery	Headcount of development personnel and number of languages or frameworks covered. Internal courses built on the process lower the cost.
Evidence upkeep	Recurring	Internal document owners and engineers who keep the process, training records and review records current	Frequency of significant enterprise changes that trigger updates, plus the annual documentation review. Versioned repositories reduce effort.
External testing or review	Recurring or per engagement	Independent testing firms or assessors, paid per written scope	Number and complexity of applications, use of authenticated testing and third-party code volume. Clear scope limits cost.
Auditor sampling and assessment	Recurring per assessment cycle	Independent auditor or assessor who samples evidence; the organization pays for the assessment and for preparing samples	Regulatory scope that requires this safeguard, number of teams sampled and quality of evidence on file. Consistent records shorten sampling.

Which self-hosted open-source tools can produce secure development evidence

Safeguard 16.1 is a documented process, so the strongest evidence is a record of how code moves, how it is checked and how decisions are written down. The four tools below each produce one part of that record, and none of them makes an enterprise compliant on its own. Confirm each feature in your own environment before relying on it.

GitLab Community Edition

Protected branches restrict which roles can push or merge to a branch, can block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. These settings show that changes to production code pass through a reviewed path, which is the change control evidence an assessor will ask to see for the development process. The MIT license permits commercial use. Confirm that your chosen edition and version include the protected branch options you plan to rely on.

Semgrep Community Edition

Semgrep scans source code in languages including Java, Python, Go, JavaScript, TypeScript and Terraform, using community rules or rules your team writes. Running it in CI/CD pipelines produces repeatable scan results for each change, which supports the security testing part of the process. The LGPL-2.1-only license requires care if you modify the tool itself. Confirm the language coverage for your stack and check whether your team needs commercial rule packs for the findings you must track.

XWiki

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. This gives you a dated history of the secure development standards, threat assessments and review records that Safeguard 16.1 requires you to keep current. Confirm that the version history and retention settings meet your own documentation retention rules, since an assessor may ask for the version in force on a given date.

BookStack

BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets you give developers edit rights on the development process content and reviewers approval rights, while keeping the controlled documents read-only for others. The result is a record of who can change the process documentation. Confirm that your role design matches the approval steps you document, and that changes are traceable in your environment. The MIT license permits commercial use.

Who owns the process, who can prepare it and who must independently test it

Your organization owns Safeguard 16.1. The secure development process is an internal governance decision, and it has to reflect your products, your risk appetite and the teams that actually build software. Nobody outside the enterprise can accept the residual risk of its applications or decide how it trades off delivery speed against security. Your team sets the standards, approves the written process and decides what happens at each annual review.

Process ownership: Name an accountable owner, usually in security or engineering leadership, who maintains the process document and answers for gaps.
Standards and approvals: Approve the design standards, secure coding practices and testing procedures, and record who signed off and when.
Training: Run developer training in-house or commission it, and keep attendance and content records.
Risk acceptance: Decide which exceptions to the process are acceptable, document the reasoning and set an expiry date.
Annual review: Make the review decision, and trigger an earlier review after significant changes such as a new platform, an acquisition or a new class of third-party code.

Before any assessment, confirm that the owner, approvers and review cadence are written down and that they match how teams actually work.

Where organizations usually fall short on Safeguard 16.1 and how to close each gap

Most enterprises that fail Safeguard 16.1 already have some development practices in place. The gaps usually sit in the written process, its scope, and whether the repositories, pipelines and training records match what the document says. Each card below names one gap and the evidence that closes it.

The process exists but is not written down

Teams often follow informal habits such as code review by a senior engineer or a security check before release, but nothing is documented. Safeguard 16.1 is measured against a documented secure application development process, and an undocumented one scores as if it were absent. Check whether design standards, coding practices, training, vulnerability handling, third-party code rules and testing procedures appear in one controlled document. Evidence that closes it: an approved, versioned process document with an owner and an approval record.

The scope omits contractors and acquired software

A process written for in-house employees often ignores code written by contractors, offshore teams, or software bought or inherited through acquisitions. The Completeness metric counts the share of components the process covers, so every development source you use should be named in scope. List each internal team, contractor firm, outsourced developer and acquired codebase, then state which parts of the process apply to each. Evidence that closes it: a scope statement that names these sources and a register of the applications they maintain.

Third-party code sits outside the process

Open-source libraries, vendor SDKs and generated code often enter applications without passing through design review, testing or vulnerability intake. The process should say how third-party code is selected, approved and tested before it reaches production, and who owns the decision. Confirm that the process points to the component inventory and selection rules covered by Safeguards 16.4 and 16.5. Evidence that closes it: a written third-party code clause with an approval step, plus pipeline records showing dependency scans on builds.

Training is not tied to the process

Developers may complete a generic security course, but the course does not cover the coding practices, design standards or tools the process requires. Safeguard 16.9 asks for secure coding training for developers at least annually, and the process should name the training that supports each step. Check whether the training catalog maps to the process sections and whether new hires receive that training before their first commit. Evidence that closes it: a training matrix linking each process step to a course, with completion records by team.

The annual review is skipped or undated

CIS asks for the Safeguard 16.1 documentation to be reviewed and updated annually, or sooner when significant enterprise changes could affect it. Many organizations revise the document only after an audit finding, and the file carries no review date. Set a review date, record who reviewed the document and what changed, and add an extra review trigger for major architecture, tooling or acquisition changes. Evidence that closes it: revision history showing each annual review, a named approver, and dated change notes.

The document and the repositories disagree

The process may require peer review and protected release branches, while repository settings allow direct pushes to the main branch and force pushes that rewrite history. An assessor will compare the written rules against the configuration. Review branch protection on every production repository, confirm that required reviewers and security scans are enforced in the pipeline, and record any exceptions with an owner. Evidence that closes it: exported repository settings, pipeline configuration files, and an exception log that matches the document.

Questions buyers ask about the cost, effort and timing of Safeguard 16.1

How much effort does it take to write a secure application development process?

The effort depends mainly on how many teams build software, how many languages and platforms they use, and whether any written practices already exist. A small organization with one product team may need a short document that covers design standards, coding practices, developer training, vulnerability management, third-party code and security testing. A larger one must describe how each team applies those rules, which means more interviews, more reconciliation of conflicting practices and more review cycles. Ask any provider to break the effort into discovery, drafting, review and rollout, and to state which of those steps your own staff will perform.

Can we write the process ourselves without outside help?

Yes. Safeguard 16.1 is a documented process, and the organization owns it, so internal staff can write it. An outside implementation partner can help with the parts that are slow or specialized, such as mapping existing practices to the six topics the safeguard names, setting up the tooling that produces evidence, or building a repeatable review cycle. Only an independent assessor or auditor can confirm that the process meets a framework or contract requirement. Decide early who will hold the document and who will approve changes.

What does the work need from engineering, security and product leaders?

Engineering leaders must confirm which practices developers actually follow, because the process will fail if it describes work nobody does. Security leaders own the design standards, the testing expectations and the vulnerability handling rules. Product leaders set priorities for fixes and decide how exceptions are approved when a release deadline conflicts with a security finding. Each group should name one accountable person and agree on how disputes are settled. Without those owners, the document tends to stall in draft.

How long does it take to get a secure application development process in place?

The timeline depends on how many teams, products and environments the process must cover, how mature current practices are, and how much review and approval the organization requires. Ask for a timeline in the written scope rather than relying on a general estimate, and make sure it lists the approvals, interviews and rollout steps separately. CIS does not supply a duration for this safeguard, so treat any figure you receive as the provider's estimate for your environment and confirm the assumptions behind it.

Do organizations in Implementation Group 1 have to meet Safeguard 16.1?

No. CIS places Safeguard 16.1 in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1. IG1 covers essential cyber hygiene for every enterprise, and it does not include this safeguard. An IG1 organization that builds its own software may still choose to document a development process because it reduces risk, but it is not required by the Controls to do so. Confirm your Implementation Group against the CIS Implementation Groups pages before you scope the work, and check whether any contract or regulation you are subject to asks for more than the Controls do.

What must the annual review of the process contain?

CIS asks that the Safeguard 16.1 documentation be reviewed and updated annually, or sooner when significant enterprise changes could affect it. The review should confirm that each of the named topics is still covered, that design standards and coding practices match current technology, that developer training is current, and that vulnerability management and third-party code rules still reflect how teams work. Record who reviewed the document, the date, the changes made and the reasons for them. That record is the evidence an assessor will ask to see.

Can an implementation partner issue an audit result for Safeguard 16.1?

No. An implementation partner can prepare the process, the documentation, the tooling and the evidence, but it cannot issue an audit report, attestation or certification. Only an independent auditor, assessor or certification body can test the safeguard and report on it. Ask any partner to state in writing what it will deliver, which items are for your records, and which items an independent assessor must review. Separating those roles keeps the assessment credible and avoids paying for work that a reviewer will later reject.

How DeployOpen scopes, implements and prepares evidence for Safeguard 16.1

DeployOpen helps organizations set up the systems, documentation and evidence that a secure application development process needs, inside the client's own infrastructure. The organization owns its development process and its CIS Controls decisions, and an independent assessor or the client's own reviewers judge whether the safeguard is met.

How we scope

Written scope lists which application teams, repositories, pipelines and third-party code sources fall inside the secure development process.
Scope records the design standards, coding practices and testing procedures the client already uses, so gaps are visible before work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any implementation begins.

How we build

Configure protected branches in a self-hosted GitLab instance so maintainers control who can push or merge to production code.
Add Semgrep scanning to CI/CD pipelines with community or custom rules matched to the languages the client's teams actually use.
Set up a version-controlled wiki or documentation platform so the process document records changes, authors and approvals over time.

How we hand over

Deliver the written secure development process, mapped to the Completeness measure in the CIS Controls Assessment Specification for Safeguard 16.1.
Provide configuration records, pipeline definitions and access settings that show the process operates, not only that it is written.
Document the annual review cycle and the triggers for earlier review, so the client's own staff can keep the evidence current.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover periodic review of the process document when significant enterprise changes could affect the safeguard.
Confirm with the client's auditor or assessor which evidence formats and sampling they expect before the handover is finalized.