Safeguard 16.10 Secure design principles

What CIS Safeguard 16.10 asks for in application architecture

If you run an IG2 or IG3 enterprise that builds or hosts software, Safeguard 16.10 asks you to show that your application architectures apply secure design principles, and that the design decisions behind them are documented and can be checked. In plain terms, the Safeguard expects your designs to limit what any single user, component or flaw can reach. The two principles named in the Safeguard are least privilege, meaning each component and account gets only the access it needs, and mediation, meaning every user operation is checked against policy rather than trusted once at login. Alongside these, the CIS examples call for documented validation of all input for size, data type and acceptable range or format, and for reducing the attack surface by disabling unprotected ports and services, removing unneeded programs and files, and renaming or removing default accounts.

The risk behind the Safeguard is a design that lets one flaw expose everything. A single injection bug in a service with broad database rights, or an admin endpoint reachable without a check on each request, can turn a small defect into a full data exposure. Secure design limits that blast radius before any code is reviewed. The Safeguard is hard to meet for a simple reason: architectures are rarely written down in a form that a reviewer can test. Teams often rely on experience and conventions that exist only in people's heads, so the first practical step is to decide which design standard your teams will follow and record it in your secure development process. The Safeguard sits in the Software asset class and the Protect security function, and it is placed in Implementation Group 2, so IG1 enterprises do not carry it. Its assessment depends on Safeguard 16.1, the secure application development process, so confirm that process exists before you plan evidence for 16.10.

Start by confirming with your assessor which application infrastructure components and designs fall in scope, because the assessment specification measures the share of those components where design principles were applied. Ask the assessor how they will treat a design framework that exists on paper but is not followed in reviews. Then decide who owns the design standard, how architecture reviews record their decisions, and which entry points and privileges each review must examine. Those decisions drive most of the work and most of the cost of meeting the Safeguard. Read the CIS Controls Assessment Specification for Safeguard 16.10 to confirm the measures your assessor will use before you define your evidence set.

Which applications, teams and third parties Safeguard 16.10 covers

Safeguard 16.10 sits in IG2, so the first scoping question is whether it applies at all. Once it does, the work depends on which applications and infrastructure components fall under the Compliance metric, which teams hold architecture authority, and how vendor-managed platforms are handled. Settle these decisions in writing before counting effort.

Applicability by implementation group

Safeguard 16.10 is assigned to IG2 and IG3, so an IG1 enterprise does not measure it. An IG2 or IG3 enterprise should confirm its group in writing, because the group determines whether this Safeguard is in scope at all. Effort rises sharply once the Safeguard applies, since it depends on Safeguard 16.1 already defining a secure development process. Check that prerequisite first.

In-house, hosted and acquired applications

The assessment asks about the applications the enterprise builds, runs or buys, so an inventory of all three is the starting point. In-house code needs design review against secure design principles, while hosted and acquired applications need the enterprise to ask for evidence from their owners. Teams should list each application with its owner, data sensitivity and entry points before estimating work.

Infrastructure components under the compliance metric

The Compliance metric measures the share of application infrastructure components where design principles were applied, so the denominator must be defined. Components include application servers, databases, message queues, APIs and gateways that support each application. Agree the component list with the platform team, because an undefined denominator makes the score impossible to reproduce.

Architecture decision ownership

Least privilege, input validation and attack surface reduction are decided in design reviews, not in code alone. Name the role that approves architecture for each application, such as a lead architect or security architect, and record who signs off deviations. Developers, product owners and security staff each need a defined part, or the design framework exists only on paper.

Vendor-managed SaaS and PaaS

For SaaS and PaaS, the enterprise usually cannot change the platform's internal architecture, but it still configures access, data exposure and integrations. Scope the controls the enterprise owns, such as roles, API scopes and default accounts, and collect the provider's assurance evidence for the rest. Confirm the contract gives access to that evidence, since the Safeguard expects the enterprise to show its own design choices.

Shared controls with other Safeguards

Design principles overlap with the Safeguards for secure development, hardening and threat modeling, so the same evidence can be reused if it is mapped once. Where a design review is also a threat model, record it in both places rather than duplicating the review. Confirm with the assessor which evidence counts for which Safeguard before preparing packages.

How least privilege and mediation show up in architecture decisions

Applying secure design principles to Safeguard 16.10 means making specific architecture decisions early, before code is written. The first is least privilege for every component: each service, job and service account should hold only the permissions its function needs, and nothing should run with broad database or cloud rights because it was convenient during development. Mediation is the second decision. Every user operation, such as viewing an invoice, changing a role or exporting records, should be checked by the server or a shared authorization layer against the user's entitlements. A hidden button in the interface is not a control, so the team should be able to show where each sensitive operation is authorized in code.

Input validation is the third decision. Teams should document the rules for every input field, API parameter and file upload: maximum size, expected data type, and an acceptable range or format. Those rules belong in a shared validation layer or schema so they are applied consistently and can be reviewed. Attack surface reduction is the fourth. Architects should decide which ports, services, debug endpoints and sample files will not ship, and which default accounts will be renamed, disabled or removed before go-live. Confirm these choices against the secure design framework and the secure development process your organization has written under Safeguard 16.1, because the assessor will look for both.

*Illustrative example:* a payments team builds an internal reporting service that reads from a reporting database. Under least privilege, the service account gets read-only access to two named views rather than the whole schema. Mediation means the API checks each report request against the caller's role. Validation rejects date ranges longer than the approved window and any parameter that is not an expected type. The team also disables the debug port and removes the sample data loader before deployment. Each of these decisions can be traced to a design record and a configuration check, which is the kind of evidence an assessor will ask to see.

How an assessor tests CIS Safeguard 16.10

This table compares what an assessor checks for Safeguard 16.10 across the test approach, evidence, scoring metric, prerequisite, failing condition and common findings. The CIS Controls Assessment Specification defines what to measure, not how, so assessors choose their own method and organizations should confirm it with their assessor before testing starts.

Assessment element	What the assessor looks for	Where it usually fails
Test approach	Sample application architectures and trace whether design principles such as least privilege and input validation appear in the design and the built code	Assessor samples only the newest application, so older systems with no documented design are never tested
Evidence requested	Written secure design standards, architecture or design documents, threat or design review records, and code review comments that reference the principles	Designs exist only in whiteboard photos or in engineers' memory, with no version history or approval record
Compliance metric	The share of application infrastructure components where design principles were applied, counted against the in-scope inventory	The inventory of application components is incomplete, so the denominator is understated and the score looks better than it is
Prerequisite check on 16.1	A documented secure application development process that the design principles are part of	No secure development process exists, so the 16.10 measurement cannot start
Failing condition	No secure design framework in the development process, which produces a failing score for this Safeguard	Teams follow informal habits, and the organization assumes general practice counts as a framework
Least privilege and mediation	Access checks run on every user operation, and service accounts and components hold only the rights they need	Authorization is checked only at the login screen or the API gateway, not on each back-end operation
Input validation	Documented rules for size, data type, range and format of inputs, applied at each entry point	Validation exists in the front end only, or rules are written but not tested
Attack surface reduction	Unneeded ports, services, programs, files and default accounts are removed or disabled, and default account names are changed	Debug endpoints, sample files or default administrator accounts remain in production builds
Common findings	Undocumented designs, unvalidated inputs, broad service permissions and unreviewed exceptions	Findings are closed by a ticket without evidence that the design was updated

Evidence that passes CIS Safeguard 16.10 and how to keep it current

An assessor testing Safeguard 16.10 looks for written design rules, design records that show those rules were applied, and measurable coverage across application components. Each artifact below can be kept current by tying it to the change and review processes teams already run, so evidence is ready when the assessment comes around.

Written secure design framework

This is the documented set of design principles your application teams are expected to follow, including least privilege, mediation of every user operation and minimized attack surface. It sits under the secure development process described in Safeguard 16.1, which the assessment specification names as a prerequisite. Confirm that the framework exists, has an owner, and is referenced from your development standards. Without it, the assessment specification scores Safeguard 16.10 as failing. Review it at least annually and after major architecture changes.

Threat-informed design records

For each significant feature or service, keep a short design record that states who can access what, which operations are mediated, and why each privilege was granted. Written records show least privilege and mediation decisions were made on purpose rather than assumed. Keep them in the same repository or ticketing system as the code so they are versioned. To stay current, require the record to be updated whenever a new entry point, data store or role is added.

Input validation standards

A validation standard lists the rules every input must pass before processing, expressed as documented size, data type and acceptable range or format rules. CIS examples for this Safeguard call for documented error checking of all input against these rules. Show the standard alongside sample code or test cases that enforce it. Keep it current by adding the standard to code review checklists and by updating it when new input sources, such as APIs or file uploads, appear.

Attack surface baselines

A baseline records the ports, services, default accounts and unneeded programs or files that each application component is allowed to keep. CIS examples for this Safeguard include turning off unprotected ports and services, removing unneeded files, and renaming or removing default accounts. Compare each deployed component against its baseline on a schedule and after each release. Differences show either drift or an undocumented change that needs a decision.

Design review records

Design reviews are the moments when a proposed change is checked against the design framework before it is built. Record the reviewer, the date, the principles checked, the decisions made and any accepted risks. Tie the review to change requests so that a change touching authentication, data flows or exposed interfaces cannot merge without a linked review. Sample these records during internal checks to confirm reviews happen for the changes that matter most.

Coverage metric data

The assessment specification scores Safeguard 16.10 with a Compliance metric: the share of application infrastructure components where design principles were applied. Track this as a simple count of components with a current design record and baseline, divided by the total in scope. Confirm with your assessor how they define the in-scope component list before you start measuring. Refresh the figure from your component inventory each review cycle so the numerator and denominator stay accurate.

How to implement Safeguard 16.10 in an application program

This sequence moves secure design principles from a documented intent to a measured portfolio practice. Each step produces an artifact that an assessor can inspect, and the final step produces the Compliance metric the CIS Controls Assessment Specification uses to score the Safeguard.

Confirm the Safeguard 16.1 secure development process
Before writing design rules, check that a documented secure application development process exists, since the CIS Controls Assessment Specification lists Safeguard 16.1 as a prerequisite for measuring Safeguard 16.10. The security lead and the engineering manager review the existing process document to confirm it names design standards, developer training, code review and security testing. The output is a short gap list showing which of those elements are missing, and the step is done when the owner accepts the list and assigns each gap to someone.
Adopt a written secure design framework
Select or write a secure design framework that states the principles the organization expects in application architectures, including least privilege and mediation of every user operation. The application security lead drafts it, and architecture and engineering leaders approve it through the same change process used for other engineering standards. The output is a signed, versioned framework document. Under the assessment specification, having no secure design framework in the development process results in a failing score, so this artifact is the first thing an assessor will ask to see.
Define input validation and mediation standards
Translate the framework into testable rules for input handling and access checks. The standard should require documented error checking of all input for size, data type and acceptable ranges or formats, and it should require an authorization check on each operation rather than only at the entry point. Architects and senior developers write the standard with examples for the languages and frameworks the organization uses. The output is a validation and mediation standard with code examples, and the step closes when at least one reference implementation passes a peer review.
Set attack surface baselines
Define what a minimal application footprint looks like for each infrastructure type the portfolio uses. The baseline covers turning off unprotected ports and services, removing unneeded programs and files, and renaming or removing default accounts. Platform engineers draft the baselines and check them against the hardening templates used under Safeguard 16.7. The output is a baseline document per component type, and the step closes when a sample deployment is scanned and its findings are either fixed or accepted with a recorded reason.
Apply the principles to a pilot application
Choose one application that represents a typical design pattern in the portfolio and apply the framework, validation standard and baselines to it. Teams record design decisions, such as access roles, trust boundaries and exposed endpoints, in a design record and review them with the security team. Where possible, enforce checks in the pipeline using tools such as Semgrep, which can run custom rules in CI/CD, and protect the main branch with GitLab protected branches so reviewed design changes merge in a controlled way. The output is a pilot design record and a list of lessons that feed back into the standard.
Extend the practice across the portfolio
Roll the standard into the development process for the remaining applications, prioritized by data sensitivity and exposure. Each team adds the design review to its existing intake or architecture review, and the security function tracks which applications have a completed design record. The output is a portfolio register that lists each application, its design review status and its exceptions with approvers. The step closes when every in-scope application has either a completed design record or an approved exception.
Measure the Compliance metric
Calculate the share of application infrastructure components where the design principles were applied, which is the Compliance metric the assessment specification uses for Safeguard 16.10. The security function produces a coverage report from the portfolio register and the pipeline results, and the report is reviewed by the owner of the secure development process. The output is a dated coverage report with the numerator, denominator and exceptions listed, and it should be repeated on a schedule the organization sets. Ask an assessor early which evidence format they expect, because the report is only as credible as the records behind it.

Open-source tools that support Safeguard 16.10 evidence

Both tools produce records that support the design side of Safeguard 16.10: who may change application code, and whether that code is checked against the team's validation and mediation standards. Neither tool decides whether a design is sound, so the organization still needs documented design principles and review records that the tools' output can be matched against.

Protected branches in GitLab

GitLab Community Edition is MIT-licensed and includes protected branches. Maintainers can restrict which roles may push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. For Safeguard 16.10, this supports controlled change to design-relevant code, such as authorization checks, input validation layers and shared security middleware, which must pass through a reviewed path. The setting shows who could change the code, but it does not prove the design was sound. Check that branch settings are exported or captured with dates, and that they match the approval rules in your secure development process.

Custom code rules in Semgrep

Semgrep Community Edition is LGPL-2.1-only and scans languages including Java, JavaScript, TypeScript, Python, Go, C#, Kotlin and Terraform. It runs with community rules or custom rules that encode your validation and mediation standards, such as flagging a request handler that uses a parameter before any defined input check, or a Terraform resource that exposes a service beyond its intended network. It can run in CI/CD pipelines to scan repositories continuously. Confirm the LGPL-2.1-only license terms for your intended use, including any embedding or distribution, before relying on it in a regulated environment. Rule results support the checks, but a clean scan does not show that the design principles were applied.

What meeting CIS Safeguard 16.10 costs in money and effort

This table breaks down the money and effort behind Safeguard 16.10 by cost component, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No fees are stated because none are supplied; use the table to structure a written scope and quote request. The main takeaway is that the largest recurring cost is usually keeping design reviews and evidence current as the application estate changes.

Cost component	One-time or recurring	What drives it up or down	What to request in a quote
Tooling and licenses	Recurring, if commercial	Number of repositories and languages scanned; Semgrep Community Edition (LGPL-2.1-only) and GitLab Community Edition (MIT) can remove license spend, but confirm feature fit	Itemized list of tools, license terms, and any paid tiers needed for scanning or protected-branch controls
Architect and engineering time to write the secure design framework	One-time, with periodic revision	Number of application architectures and teams; the framework is a prerequisite under Safeguard 16.1, so an existing secure development process shortens this work	Deliverables, named roles, and hours by role, tied to a written scope
Design reviews and principle checks	Recurring	Application count, release frequency and how many designs change architecture each cycle; new services multiply review work	Review workflow, review triggers, and effort assumptions per design review
Evidence upkeep	Recurring	Frequency of audits and assessments; the Compliance metric needs current records of which applications and infrastructure components applied the principles	Evidence list, collection cadence, and who maintains the records after handover
Legacy estate remediation	One-time, then variable	Age and count of legacy applications lacking documented input validation, default account handling or minimized attack surface	Inventory-based estimate separating legacy remediation from new-build design work
External architecture or penetration review	Recurring or per engagement	Scope of applications under review, IG level, and whether authenticated testing is included under Safeguard 16.13	Named scope, testing depth, and whether findings are retested
Auditor or assessor sampling	Recurring, per assessment cycle	Number of applications sampled and the depth of evidence requested; the assessor issues any report, not the implementation partner	Confirm with the assessor how many samples they expect and what evidence format they accept
IG level scope	Applies to the whole program	IG2 and IG3 enterprises carry Safeguard 16.10; IG1 does not, so an IG1 organization can defer this cost unless it adopts the safeguard voluntarily	Written confirmation of the Implementation Group that sets the applicable scope

Who does what for Safeguard 16.10: your team, a partner and the auditor

Your organization owns Safeguard 16.10. The CIS Controls Assessment Specification scores the Safeguard on a Compliance metric, the share of application infrastructure components where design principles were applied, and it fails the Safeguard outright if no secure design framework exists in the development process. Only your people can define that framework, make the architecture decisions it governs and accept the residual risk when a design trade-off is made.

Design framework ownership: Write and approve the secure design principles your applications must follow, including least privilege, validation of every user operation and attack surface minimization.
Architecture decisions: Review and sign off designs for significant applications, and record exceptions and the reasons for them.
Metric and scope: Define which application infrastructure components count toward the Compliance metric and calculate the share on a repeatable schedule.
Prerequisite process: Establish the secure application development process under Safeguard 16.1, which the assessment specification lists as a prerequisite for measuring 16.10.
Ongoing operation: Keep developers accountable for applying the framework to new and changed components.

Before engaging anyone else, confirm that a named owner can explain the framework and the metric to an assessor without outside help.

Questions buyers ask about meeting Safeguard 16.10

How much effort does meeting Safeguard 16.10 take?

Effort depends mostly on how many applications and infrastructure components are in scope and how far their design already reflects secure design principles. The CIS Controls Assessment Specification scores 16.10 with a Compliance metric: the share of application infrastructure components where design principles were applied, so the work is measured per component. Teams with few applications and a documented architecture review step will need less effort than teams with many legacy services and no design standard. Ask the provider to break the estimate down by application, by component type and by remediation work, and to state which of those items are excluded.

What drives the time needed to reach a first evidence set for 16.10?

The main drivers are whether a secure design framework already exists in the development process, how many teams build software, and how much of the architecture is documented. The assessment specification gives 16.10 a failing score if no secure design framework is part of the development process, so writing and adopting that framework is often the first dependency. Other drivers include the number of review cycles needed for existing applications, access to architects who can confirm design decisions, and whether pipeline tooling for repository controls is already in place. No duration is given here; ask for a timeline tied to named milestones in the written scope.

Can our own team meet Safeguard 16.10 without an outside partner?

Yes, the organization owns its controls, so internal teams can design, document and evidence secure design principles themselves. Internal work usually needs a named owner for the design framework, architecture reviews that record least privilege decisions and input validation rules, and a way to show which components were reviewed. An outside implementation partner can help prepare systems, templates and evidence, but cannot issue an assessment result. If your team has no experience with architecture reviews or with mapping design decisions to components, budget time to learn that before the first assessment.

What does the work need from our architects and developers?

Architects need to define the secure design principles, such as least privilege and mediation of every user operation, and apply them to the architecture of each application. Developers need to implement input checks for size, data type and acceptable ranges or formats, and to remove unneeded services, files and default accounts from the components they run. Both groups should record decisions in a form that an assessor can trace to a component. Plan time for review sessions, for fixing findings, and for keeping records current when designs change.

Can an implementation partner issue the CIS assessment for Safeguard 16.10?

No. An implementation partner can prepare the design framework, the review records and the technical evidence, but only an independent auditor, assessor or certification body issues reports or certificates. DeployOpen plans, implements, hardens and documents systems inside the client's own infrastructure and prepares evidence for compliance assessments, but it does not issue assessment results. Ask any provider to state in writing which deliverables are preparation and which, if any, come from an independent party, and who signs off the final evidence.

How does Safeguard 16.10 relate to 16.1 and 16.13?

Safeguard 16.1 is the governing safeguard for the secure development process, and the CIS Controls Assessment Specification lists it as a prerequisite for measuring 16.10, so a documented development process is needed first. Safeguard 16.10 then covers the design principles applied within that process. Safeguard 16.13 covers application penetration testing, which tests whether the design holds in practice, including business logic flaws that scanners miss. Design reviews reduce the number of issues that penetration tests find, but they do not replace testing, so plan both.

What should we ask for in a written scope for Safeguard 16.10 work?

A written scope should list the applications and infrastructure components in and out of scope, the secure design framework to be produced or reviewed, and the review process for each architecture. It should name the evidence to be delivered, such as design records, input validation specifications, configuration baselines and repository controls, and state who holds each item. Ask for the dependencies on 16.1, the assumptions about existing documentation, the client responsibilities, the change control method, and the acceptance criteria. Also ask how the assessment will be run and by whom, since that party is not the implementation partner.

How DeployOpen prepares Safeguard 16.10 evidence

DeployOpen plans, implements and documents the design controls behind Safeguard 16.10 inside your own infrastructure, so your team can show how least privilege, input validation and attack surface reduction are applied. Your organization owns its controls, and an independent assessor decides whether the evidence meets the CIS Controls Assessment Specification.

How we scope

We agree a written, fixed scope listing which applications, environments and architectures fall under Safeguard 16.10.
We confirm the prerequisite secure application development process from Safeguard 16.1 is in place before design work starts.
Ongoing support, upgrades and continuous testing can be added later as a retainer, priced separately from the fixed scope.

How we build

We document the secure design principles your architectures apply, including least privilege and mediation of every user operation.
We configure input validation rules for size, data type and acceptable ranges or formats, and record them as reviewable design artifacts.
We reduce attack surface by closing unneeded ports and services, removing unused programs and files, and renaming or removing default accounts.

How we hand over

We deliver the design documentation, configuration records and repository settings that show the principles are applied in code and infrastructure.
We record the Compliance metric inputs, meaning the share of application infrastructure components where design principles were applied, so your team can track it.
We confirm with your assessor which evidence formats they accept, since only an independent auditor issues any report or certificate.

How we support

We review design decisions whenever an application changes architecture, so the documented principles stay current with the running system.
We can run periodic reviews of input validation and attack surface settings under a retainer if your team wants ongoing checks.
We help your team prepare for assessor questions, but the organization remains responsible for operating and proving its controls.