What Safeguard 16.14 asks for before code is written
Safeguard 16.14 requires threat modeling of applications before code is created, carried out by specially trained individuals who evaluate the application design and gauge security risk for each entry point and access level. For an IG3 enterprise, or one preparing for a CIS assessment, the practical question is whether every in-house application can show a documented threat model produced by people who know how to build one. The aim is to catch design flaws (such as an unauthenticated administrative path, an unchecked trust boundary between services, or a role that can reach data it never needs) while changing the design is still cheap. Code review and scanning find defects inside a design; threat modeling asks whether the design itself is sound.
Safeguard 16.14 sits in Implementation Group 3 only because it presumes a mature development function, enterprise-scale application portfolios and sensitive assets facing targeted attacks. CIS places it in the Software asset class and the Protect security function. The Assessment Specification scores it with a Compliance metric: the share of in-house developed applications that underwent threat modeling. A missing threat modeling process fails the safeguard outright, so the first decision is whether a defined, repeatable process exists at all. Confirm the current scoring language and any prerequisite measures directly in the CIS Controls Assessment Specification for Safeguard 16.14 before you build a plan around them.
Three things usually make this hard. The first is the absence of a defined process, so teams model some applications informally or not at all. The second is the lack of a software inventory: the Assessment Specification lists Safeguard 2.1 as a prerequisite, so you cannot prove the share of applications modeled until you know which applications exist. The third is the small pool of people trained to model threats. Plan for that gap early by deciding who owns the process, which architects or developers will be trained, and how threat models will be stored and refreshed when designs change. Those decisions, not the modeling exercise itself, are what an assessor will ask to see first.
Which applications and teams fall under threat modeling
The Safeguard 16.14 Compliance metric counts in-house developed applications that went through threat modeling, so scope starts with knowing which applications the enterprise builds. The cards below cover the inventory that anchors that population, the entry point and access level analysis that makes a model useful, and the people whose input the review depends on.
In-house developed applications as the population
The measured population is the set of in-house developed applications, not every system the enterprise runs. Decide which codebases count, including internal tools, customer portals, APIs, batch jobs and scripts that handle sensitive data. Record the owning team and the repository for each one. Hosted or acquired software is outside the Compliance metric unless the enterprise builds or customizes on top of it, so document that boundary in writing and confirm it with the assessor before the first measurement.
Software inventory as the scoping source
Safeguard 2.1, the requirement to establish and maintain a software inventory, is the prerequisite the assessment specification lists for measuring Safeguard 16.14. Use it to find applications that development teams do not announce, such as shadow services and forgotten internal tools. Check that each in-house application in the inventory carries an owner, a version and a classification. An inventory that omits applications produces a denominator that looks healthy but does not reflect reality.
Entry points and access levels
A threat model is only as complete as its list of entry points and access levels. For each application, record every interface where data or commands enter, including web forms, REST and GraphQL endpoints, message queues, file uploads, admin consoles and scheduled imports. Then record which roles or identities reach each one, from anonymous users to privileged administrators. Scoping decisions should state whether each entry point is in or out of the model, so the reviewer can see why a path was skipped.
Trigger events that bring an application into scope
Set the rules for when an application must be modeled. Common triggers include a new application, a change to authentication or authorization, a new external integration, a new data classification for stored records, and a move to a new hosting model. Write these triggers into the secure development process so teams know when a model is required. Without triggers, the metric depends on whether someone remembers to ask, and the population drifts as applications change.
Architecture, development and security participants
Threat modeling needs people who know the design, the code and the risk. Architecture owns the data flows and trust boundaries. Development supplies the implementation detail, such as how sessions and tokens are issued. Security, staffed by people trained in threat modeling, challenges assumptions and records risks. Name a facilitator for each model and confirm the attendees in the record, since the safeguard asks for trained individuals and the assessor will look for that evidence.
Records that prove the population
Keep a register that lists each in-house application, its scope status, the date of its threat model and the people who signed off. Versioned documentation helps here, because the model should show what changed between reviews. Confirm with your assessor which documentation format and retention period they accept. The register is what turns the Compliance share from an estimate into a number that can be traced back to each application.
How an assessor tests Safeguard 16.14
This table walks through how an assessor applies the CIS Controls Assessment Specification to Safeguard 16.14, from the prerequisite software inventory to the Compliance metric and the evidence requested. Read it as a checklist of what the organization must be able to show before the assessment starts, since a missing population or undocumented models are the most common reasons a score falls short.
| Assessment element | What the assessor checks | Evidence the organization should have ready |
|---|---|---|
| Prerequisite inventory | Safeguard 2.1 (software inventory) must exist first, because the assessor cannot confirm the population of in-house applications without it | Current software inventory with in-house applications flagged, owners named and last review date recorded |
| Population definition | The assessor confirms the list of in-house developed applications is complete, including internal tools, hosted apps and components built by contractors for the enterprise | Population list reconciled against the software inventory and source control repositories, with the reconciliation dated |
| Compliance metric | The score reflects the share of in-house developed applications that underwent threat modeling, so each application in the population is tested individually | Per-application record showing whether a threat model exists, its date and the reviewer who approved it |
| Failing condition | A failing score applies if the enterprise has no threat modeling process at all, regardless of how many individual applications were reviewed | Written threat modeling process that defines when modeling happens, who performs it and how entry points and access levels are evaluated |
| Model quality review | The assessor samples threat models to confirm they evaluate the application design, each entry point and each access level, and that they were done before code was written | Threat models with diagrams, identified entry points, access levels, identified threats, mitigations and design-phase dates |
| Trained personnel | The assessor checks that modeling is performed by specially trained individuals, not only by whoever is available on a given project | Training records, role descriptions or competency criteria for threat modelers, and names of people who performed each sampled model |
| Sample testing | The assessor selects applications from the population, often across different teams and release dates, and traces each back to its model | Access to the model repository, linked tickets or design documents, and the date ordering between design and first code commit |
| Common finding: undocumented models | Teams describe threat modeling in meetings but no artifact exists, so the application counts as not modeled | Versioned models stored in a system of record with owners and review history, not only in chat or slides |
| Common finding: incomplete population | Applications missing from the inventory are never tested, which inflates the apparent compliance rate | Reconciliation between inventory, repositories and deployment records, showing how new applications enter the population |
How to set up threat modeling that produces audit evidence
This sequence moves from a verified software inventory to a repeatable threat modeling process that records entry points, access levels and the design changes that followed. Each step ends with an artifact an assessor can sample.
Confirm the software inventory as the scope baseline
Before anyone models a design, confirm that the list of in-house developed applications is complete. Safeguard 2.1 is a prerequisite for measuring Safeguard 16.14, so the inventory is the starting point for the population an assessor will test. The owner of the application portfolio, usually the head of application development or the platform lead, signs off the list and marks which applications are in-house developed, which are hosted or acquired, and which are in scope for modeling. The output is a dated, versioned scope register that identifies every application in the denominator of the Compliance metric. Ask your team how they will prove the list is complete, because an assessor will compare it against your software inventory.
Define the threat modeling process and template
Write a short procedure that states when threat modeling happens, who leads it, what inputs it requires and what it produces. The procedure should require the design artifacts to be reviewed before coding starts, record each entry point and access level, and name the owner of the process. Build a template with fields for application purpose, data classification, architecture diagram, trust boundaries, entry points, roles and access levels, identified threats, mitigations, accepted risks and sign-off. Store both the procedure and the template under version control so changes are dated and attributable. The output is an approved process document and a blank template that the team can reuse for every application.
Train the individuals who run the models
Safeguard 16.14 specifies that threat modeling is performed by specially trained individuals, so the people who facilitate sessions need documented training before they lead one. Identify the facilitators, which often include a security architect or an experienced developer paired with a security engineer, and give them training on the method your organization has chosen, the template and the common threat categories. Training can come from internal courses, vendor material or an external provider. Record attendance, the course content and the date of completion for each facilitator. The output is a training roster and course record that shows which individuals are qualified to run a model. Confirm with your assessor which training evidence they will accept.
Select a sample application and model it before coding
Choose an application that is still in design, or a planned change to an existing application, and run the first model before any code is written. Gather the product owner, developers, a security specialist and the facilitator for a working session. The group reviews the architecture diagram, draws trust boundaries, lists data flows and assesses threats against the design. Keep the session notes in the template and record who attended. A review performed after development is complete does not meet the design-stage intent of the safeguard, so the timing should be visible in the record. The output is a completed model for the sample application, dated before the first commit of the feature it covers.
Record entry points and access levels
Within the model, list every entry point the application exposes, such as public APIs, administrative interfaces, batch imports, message queues, file uploads and integration endpoints. For each entry point, record which roles or identities can reach it and at what access level, from anonymous users through standard users to administrators and service accounts. The Safeguard evaluates the design for each entry point and access level, so a model that describes the application as a whole without these records will be hard to defend. Store the entry point register alongside the model. The output is a table that maps each entry point to its access levels and the threats assessed against it.
Track findings to design changes
Convert each threat the team accepts as a risk into a tracked item with an owner, a design decision and a status. Mitigations should link to a design change, such as a new authorization check, a removed endpoint or a changed data flow, and not remain as a general intention. Items the business chooses to accept should carry a named approver and a rationale. Use your existing issue tracker or a repository of issues so that each finding has a stable identifier. The output is a findings register in which every threat has a disposition and every mitigation can be traced to a design artifact. An assessor sampling the register will look for this traceability first.
Repeat the model at each design change
Threat modeling is not a one-time event for the application. Define the triggers that require a new or updated model, such as a new entry point, a change in data classification, a new integration, a change in authentication or a major architectural revision. Record the trigger in the model's revision history, and keep prior versions available so the sequence of reviews can be shown. Review the register periodically so that open items are not forgotten. The output is a revision history for each modeled application that shows the model was updated when the design changed. Confirm with your assessor how often they expect reviews and what they will accept as a trigger, because the Safeguard's wording on frequency is not repeated here.
Evidence that shows threat modeling was done
Safeguard 16.14 is scored on a Compliance metric, so the evidence has to show both the population of in-house applications and the threat models completed for them. The cards below cover the process, the models, the people, the traceability into design and backlog work, and the inventory that defines scope.
Documented threat modeling process
A written procedure that names when threat modeling happens, which applications are in scope, which method the team uses, and who approves a model. Under Safeguard 16.14, a missing process is scored as a failure, so this document is the first thing an assessor requests. Check that it names trained modelers, sets a trigger such as new applications, new entry points or major design changes, and is versioned with an owner and review date.
Threat models per application
One model for each in-house application in scope, listing its components, data flows, trust boundaries, every entry point and the access levels that reach each one. Assessors look for the link between the model and the actual design, not generic lists of threats. Illustrative example: a customer portal model would name its login endpoint, its admin API and the roles that can call each. Confirm that every model is dated and tied to the application version it describes.
Training records for modelers
Records showing that the people who build threat models completed threat modeling training and can explain the method they used. CIS describes these individuals as specially trained, so an assessor will ask who they are and how their competence was established. Keep attendance records, course names, completion dates and the list of named modelers. Update the list when staff change so that every model can be traced to a qualified author.
Risk to design and backlog links
Evidence that each risk identified in a model led to a decision: a design change, a security requirement, a test case or an accepted risk with a named owner. A model that lists threats but never reaches the backlog does not show that design flaws were addressed before code was written. Check that tickets reference the model identifier and that accepted risks are signed off by someone with authority to accept them.
Application inventory defining the population
The inventory is the denominator of the Compliance metric, so it must be complete and current. It should list every in-house developed application, its owner and whether it is in scope for threat modeling. Safeguard 2.1, the software inventory, is a prerequisite for measuring Safeguard 16.14, so assessors will test whether the two lists agree. Reconcile the inventory against code repositories and deployment records to catch applications that were left out.
Versioned models kept current
Between audits, models must track the design they describe. Store each model in version control, such as an XWiki page or a repository document, so every change records what changed, when and by whom. Update the model at each design change, record the review date even when nothing changed, and retire models for decommissioned applications. Assessors often sample the most recent change, so confirm that the latest version matches the current architecture.
Where threat modeling sits in the secure development life cycle
Safeguard 16.14 is a design-stage activity, and its evidence has to be dated before the code it describes exists. Within Control 16, Safeguard 16.1 governs the secure development process as a whole, including design standards, developer training and security testing. Safeguard 16.10 supplies the design criteria, such as least privilege, validating every operation and input, and minimizing the attack surface. Threat modeling is where those criteria are applied to a specific application: a trained team reviews the design, identifies entry points and access levels, and records the risks that the design must address. Safeguards 16.12 and 16.13 come later in the life cycle. They test what was actually built, through code-level checks and application penetration testing, and they can find flaws that a design review missed but cannot confirm that a design review happened.
For that reason, a reviewer checking 16.14 will look at the order of events, not only the existence of a model. The model should predate the implementation it describes, and the application's design should show that the model's findings were considered. A useful test is to pick one in-house application, find the threat model and compare its dates with the first commits, architecture decision records and the sprint in which the relevant feature was built. If the model was written after release, it may still be useful, but it does not show that the design was assessed before code was created. Confirm with your assessor how they want post-hoc models handled in your scope, since the assessment specification's measure is the share of in-house developed applications that underwent threat modeling.
Practically, this means the threat model needs a place in the design workflow with an owner, a trigger (for example, a new application or a material change in access or data flows) and a record that links each identified risk to a decision. Confirm that the team also keeps the software inventory required by Safeguard 2.1, since the assessment specification treats that inventory as a prerequisite for measuring 16.14. Without a current list of in-house applications, you cannot show that every application in scope was modeled.
Open-source tools that hold threat modeling evidence
Threat models stored as files in a repository can be reviewed, versioned and approved like any other change. That gives an assessor a trail showing when a model was revised and who approved the revision. GitLab Community Edition (MIT) provides protected branches, which restrict who can push or merge to a branch. Those controls matter because a threat model that anyone can silently edit is weak evidence of a design review.
- Protected branches: Maintainers can restrict which roles push or merge to the branch that holds models, and set push access to no one to block direct pushes.
- Force pushes: Keep them disabled unless explicitly allowed, so history cannot be rewritten to hide earlier versions.
- Merge requests as review records: The approval thread on a merge request can show that a named reviewer examined the model before it was accepted.
- Licensing: GitLab Community Edition is MIT licensed. Confirm which approval and access features your edition includes before you rely on them in an assessment.
Ask your team to confirm that the repository holding models has protected branch rules in place and that its approval history can be exported for an assessor.
Threat models are often written as wiki pages or structured documents, and their history matters as much as their content. XWiki (LGPL-2.1-or-later) keeps every change under version control, recording what changed, when and by whom. BookStack (MIT) controls who can view or edit model pages through roles and per-object permissions. Together they can show both the record of changes and the limits on who could make them.
- XWiki version history: Every page change is recorded, and users can compare any two versions or roll back to an earlier one.
- BookStack roles: User abilities come from assigned roles, so only designated security or architecture staff can edit models.
- Granular permissions: Permissions can be overridden at the shelf, book, chapter or page level, for example to lock a model after sign-off.
- Licensing: XWiki is licensed under LGPL-2.1-or-later and BookStack under MIT. Have counsel confirm the obligations that apply to your deployment model.
Check that the platform you choose can export page history and permission settings, since assessors often ask for both.
Static analysis results can inform a design review, but they do not identify design flaws on their own. Semgrep Community Edition (LGPL-2.1-only) scans code in many languages with community or custom rules and can run in CI/CD pipelines to scan repositories continuously. Its output is a supporting input that a trained reviewer can weigh when examining an entry point or access path, not a threat model.
- Continuous scanning: Pipeline runs record findings against each commit, which can show what a reviewer had in front of them.
- Custom rules: Teams can write rules for patterns tied to entry points, such as unauthenticated routes, so findings relate to the modeled design.
- Language coverage: The supported language list in Semgrep's documentation covers many common stacks, but confirm coverage for your own languages and infrastructure code.
- Limits: Scan results miss business logic and trust assumptions, so they cannot replace the review that Safeguard 16.14 asks for.
- Licensing: Semgrep Community Edition is LGPL-2.1-only. Confirm license terms with your legal team before distribution.
Confirm that scan results are linked to the design review record, so an assessor can see how the findings were used.
What threat modeling costs in money and effort
Threat modeling under Safeguard 16.14 costs money mainly in people's time, and most of that time is spent by trained modelers, application architects and the product owners who can explain how the application is meant to be used. The organization pays its own staff for these hours. An implementation partner or outside facilitator adds a second cost line only if the organization asks for help designing the process, running the first models or training internal modelers. Tooling is usually the smallest line. A threat model can be written in a wiki or document system, and self-hosted open-source options such as XWiki keep page history, so licence spend can be close to zero. The real effort lies in the modeling sessions themselves, so ask a vendor or partner to separate facilitation time from documentation time in any quote.
Costs fall into two timing groups. One-time costs include designing the threat modeling process, choosing a method, training modelers and producing the first models for each in-house application in scope. Recurring costs include updating a model when the architecture, entry points or access levels change, and an annual review that the process still matches how the enterprise builds software. The recurring cost is the one that is most often underestimated. Each significant design change, such as a new API, a new identity provider or a new data store, reopens the model. Because the Safeguard 16.14 assessment measures the share of in-house applications that have been modeled, every application you leave unmodeled also counts against you, so the size of the application portfolio is the biggest cost driver. Application count, change frequency, and whether applications are customer-facing or handle sensitive data all push effort up. Reusing a model template for similar applications pushes it down.
When requesting a quote, ask for the scope in writing: the number of applications, which ones are in-house developed, and how many design changes per year the work must absorb. Ask who will hold the modeler role after handover and what training is included. Ask whether the price covers the first model for each application or only the process, and whether the model format is one your team can maintain without the partner. Confirm the software inventory that the assessment specification treats as a prerequisite under Safeguard 2.1 is complete before the model count is estimated, since an incomplete inventory hides applications that need modeling. Finally, ask whether an independent review of the models is included and what it covers, because a CIS assessor will test the process and records, not the quality of the diagrams.
Who owns threat modeling and who can help
Safeguard 16.14 is an organizational obligation. The enterprise must have a threat modeling process, people trained to run it, and records showing that in-house applications were modeled before code was written. Those decisions belong to the organization because it accepts the residual risk of each design. The people who evaluate entry points and access levels should be trained individuals who understand both the application and the threats to it, and the organization must be able to show who they are and what training they received.
- Process ownership: Define when threat modeling is required, which applications are in scope, and who approves a model before development proceeds.
- Trained modelers: Name the individuals responsible for modeling and keep records of their training.
- Design decisions: Record which threats were accepted, mitigated or transferred, and who signed off.
- Software inventory linkage: Use the software inventory from Safeguard 2.1 to establish which in-house applications exist and must be covered.
- Measurement: Track the share of in-house applications that underwent threat modeling, the metric the assessment specification uses.
Confirm internally that someone accountable can name every in-house application and its modeling status today.
An implementation partner can prepare the working parts of the process so the organization's teams can run it repeatedly. This is commonly where outside help is used: building templates, setting up the documentation system, and facilitating the first models with the internal team so they learn the method. The partner prepares systems and evidence. It does not decide which risks are acceptable, and it does not certify that the process meets the Safeguard.
- Template build: Create threat model templates that capture application components, data flows, entry points, access levels and identified threats.
- Documentation system: Configure a repository for models, with version history and approval records, so changes are traceable.
- Facilitated initial models: Lead early sessions with internal staff, then hand facilitation to trained internal modelers.
- Evidence trail: Link each model to its application, owner, review date and resulting engineering tickets.
- Knowledge transfer: Document the method so the organization can run it after the engagement ends.
Ask any partner to state in writing which deliverables it prepares and which decisions remain with your staff.
An independent assessor tests whether the threat modeling process operates and whether its evidence is complete and consistent. The assessor samples in-house applications, checks that models exist and were produced by trained people before development, and compares the model against the application's actual entry points and access levels. An assessor's role is to test evidence, not to approve the security quality of the design. Issuing a clearance on a design would conflict with the assessor's independence and with the organization's ownership of its risk decisions.
- Sampling: Select applications from the software inventory and test whether each has a model dated before build.
- Training evidence: Verify that modelers were trained and that the training matches the role.
- Consistency checks: Compare model entry points and access levels with the running application.
- Exceptions: Record applications without models and the Safeguard result, which is failing if no process exists.
- Limits: Expect no sign-off on the design itself; the report describes what was tested.
Before engaging anyone, confirm that the assessor has no role in designing the models it will test.
Some parts of threat modeling are usually bought in and others are better kept internal. Initial facilitation and template construction are the most common outsourced tasks, because they require experience that most teams do not yet have. Ongoing modeling for each new feature, risk acceptance and final sign-off usually stay with the organization. The line between helping and deciding is the point where independence is at stake.
- Usually outsourced: Initial facilitation, template design and documentation setup.
- Usually internal: Routine modeling, risk acceptance and the decision to release.
- Recurring work: Model updates when architecture changes, which the process must schedule.
- Cost drivers: Number of in-house applications, architecture complexity and how many modelers you train.
- What to ask for in a quote: Written scope listing the templates, number of facilitated sessions, handover materials and which decisions the partner will not make.
Request a quote that separates one-time setup from recurring support so you can see what continues after the engagement.
Where threat modeling programs fall short at assessment
Safeguard 16.14 is assessed on whether in-house applications were threat modeled before code was written, by trained people, with the results traceable. The gaps below are the ones that most often leave a program with a failing or weak score, and each one has a practical fix an assessor can verify.
Models written after code is complete
A threat model produced once the application is built cannot change the design it was meant to examine. Assessors look for dated models that predate the design decisions they cover, and for a process that makes modeling a gate in the design stage. Check whether each model's date falls before the first implementation work on the feature it describes. Where a team modeled late, record it as a gap with a remediation date rather than presenting the model as design input. The Safeguard describes identifying design flaws before code is created, so timing is the first thing to confirm.
No defined population from the inventory
The Compliance metric counts the share of in-house developed applications that underwent threat modeling, so the denominator matters. If no one can list which applications the enterprise builds, the percentage has no basis. Start from the software inventory described in Safeguard 2.1, which the assessment specification lists as a prerequisite, and mark each entry as in-house, acquired or hosted. Keep the in-house list in the same repository or register that development uses, and review it when new projects start. An assessor will compare the modeled set against this list to find applications that were skipped.
Untrained or single modelers
The Safeguard calls for threat modeling by specially trained individuals, and a single person working alone rarely catches flaws that the team's own assumptions hide. Ask for training records for each modeler, the method they use, and evidence that more than one person reviewed the model for high-risk applications. Pair an architect with a developer and someone from operations or security where the design touches identity, data or external interfaces. Where training is outsourced, retain the course outline and completion evidence in the same location as the models.
Entry points and access levels not recorded
The Safeguard asks that modelers evaluate each entry point and access level, so a model that describes only the overall architecture will not satisfy it. Record every interface, including APIs, administrative consoles, batch jobs, message queues and third-party callbacks, and list which roles or identities can reach each one. A table with one row per entry point and one column per access level makes gaps visible during review. Assessors often sample a few interfaces and ask where they appear in the model, so keep this register current as the design changes.
Findings never linked to changes
A model that identifies risks but does not connect them to design changes or tickets shows that analysis happened without showing that it affected the software. Each finding should carry an identifier, a decision (accept, mitigate or transfer), an owner and a link to the backlog item or pull request that implements the mitigation. Keep the model in version control so changes to it are recorded with author and date. Ask the team to confirm that any mitigated finding has been verified in testing, which connects threat modeling to the Safeguard 16.13 penetration testing results.
Models stored where no one can retrieve them
Assessors need to see a model quickly, and a model stored in a personal document folder or a slide deck is hard to verify or keep current. Store models in a controlled wiki or repository with restricted editing rights and a visible history, so that the version in effect for each release can be shown. Confirm who can approve changes to a model and how often models for stable applications are reviewed. Where the team uses a wiki, check that page history records what changed, when and by whom, which gives the assessor an audit trail without additional work.
Threat modeling questions buyers ask before hiring help
Can we run threat modeling for Safeguard 16.14 without outside help?
Yes, if your team has people trained to do it and enough time to work through the design of each in-house application. Safeguard 16.14 asks for threat modeling by specially trained individuals who evaluate the application design and gauge security risks for each entry point and access level, so the organization owns the work either way. Outside help usually makes sense when no one on staff has done threat modeling before, when the first cycle needs to cover many applications at once, or when you want an independent reviewer to challenge the models. The CIS Controls Assessment Specification scores the safeguard by the share of in-house developed applications that were threat modeled, and a missing process fails outright, so the first question an assessor asks is whether the process exists and is repeatable.
How much effort and time does threat modeling take?
Effort depends on the drivers, not a fixed duration. The main ones are the number of in-house applications in scope, how many entry points and user roles each one exposes, how complex the architecture is, how much existing design documentation you have, and how many trained people can join each session. A single internet-facing application with clear documentation will take far less time than a set of interconnected internal services with unclear trust boundaries. Ask any partner to break the quote into scoping, facilitated modeling sessions, documentation of findings, and handover of the repeatable process. Confirm with your own engineering leads how much of their time the sessions will consume, because that is often the largest real cost.
What does threat modeling need from developers and architects?
It needs their knowledge of how the application actually works. Developers and architects explain data flows, trust boundaries, authentication paths, integrations and the roles that can reach each function. Without that input, the model describes the system someone imagined rather than the one in production. Expect them to review draft models, confirm which entry points exist, and agree on mitigations that fit the design. Security staff or trained facilitators typically drive the method and record decisions. A useful check is whether each model has a named owner on the engineering side who will keep it current when the design changes.
Does Implementation Group 3 apply to threat modeling?
Safeguard 16.14 is assigned to Implementation Group 3 only, so it is part of the IG3 set rather than the essential cyber hygiene baseline in IG1. CIS defines IG3 as targeting enterprises with security specialists and regulated, sensitive assets facing sophisticated, targeted attacks. An organization that is not IG3 by that description can still choose to threat model, and it may be a sound practice for its software, but the safeguard itself is measured as an IG3 requirement. Confirm your Implementation Group against CIS guidance and your own risk profile before you decide how to scope the work, and check whether any contract or regulator requires you to meet it.
How does Safeguard 16.14 relate to ISO 27001 control 8.29 and PCI DSS 12.3.2?
The CIS Controls Navigator for v8.1 maps Safeguard 16.14 to ISO/IEC 27001:2022 Annex A control 8.29 and to PCI DSS v4.0 requirement 12.3.2. The mapping is useful for planning because evidence gathered for threat modeling can often support more than one framework, but it does not mean that completing 16.14 satisfies either standard in full. ISO 27001 control 8.29 concerns security testing in development and acceptance, and PCI DSS 12.3.2 concerns targeted risk analysis for requirements that give flexibility in how often an activity is performed. Each framework has its own assessor and its own evidence expectations. Ask your auditor or QSA to confirm how they will read the mapping before relying on it.
What should we ask a partner for in a scoped threat modeling quote?
Ask for a written scope that lists the applications covered, the entry points and access levels each model will address, the number and type of facilitated sessions, and the artifacts delivered. A complete quote should also state who attends from your side, what inputs you must provide, and what happens when a design changes after modeling. Ask how the partner will record findings and link them to remediation tickets, how the process will be handed over so your team can repeat it, and how the work maps to your evidence for the CIS Controls Assessment Specification. Confirm that the partner prepares the process and evidence while your organization owns the controls and any certification is issued by an independent auditor. DeployOpen works from fixed, written scopes agreed before work starts and does not publish a price list.
Which tools help keep threat models and evidence current?
Tools rarely perform threat modeling themselves, but they keep the inputs and outputs organized. A software inventory is the prerequisite named for measuring 16.14, so start there. Version-controlled documentation helps record each model and its revisions. For example, XWiki keeps every page change under version control with what changed, when and by whom, and lets users compare versions and roll back. BookStack lets you set role-based permissions at the shelf, book, chapter or page level so only the right people can edit models. Confirm with each vendor which capabilities your chosen edition provides before you design your evidence process around them.
How DeployOpen prepares threat modeling evidence
The sequence below shows how a fixed-scope engagement turns Safeguard 16.14 into a documented threat modeling process, a current software inventory and a version-controlled evidence set that an independent assessor can test. DeployOpen prepares these materials. The organization owns its controls, and only an independent assessor issues reports or certifications.
Agree the written scope and applications
DeployOpen and the organization agree in writing which in-house developed applications fall under Safeguard 16.14, which teams and systems are involved, and which deliverables are included. Most engagements are fixed-scope, so the scope document defines the boundary before any work starts. The organization confirms who owns each application and who will attend threat modeling sessions. The step closes when the signed scope lists every in-scope application, its owner and the agreed deliverables.
Link the software inventory to threat modeling
The CIS Controls Assessment Specification lists Safeguard 2.1, the software inventory, as a prerequisite for measuring Safeguard 16.14, so the threat modeling population must come from a reliable list. DeployOpen reviews the organization's existing inventory against the in-scope applications and identifies gaps, such as applications without a recorded owner or unlisted internal tools. The organization confirms the corrected list. The step closes when every in-scope application can be traced from the inventory to a threat modeling record.
Build the threat modeling process and templates
DeployOpen drafts a written threat modeling process that defines when a design review is required, which trained individuals perform it, and how each entry point and access level is evaluated. The templates capture the application design, data flows, trust boundaries, identified threats, risk ratings, chosen mitigations and open items. The organization's security and development leads approve the process before rollout. The step closes when an approved process document and a reusable template exist, and the organization has named the trained reviewers.
Set up self-hosted documentation and version history
DeployOpen configures a self-hosted wiki or documentation platform inside the organization's own infrastructure to store threat models and the process document. XWiki keeps every change under version control, recording what changed, when and by whom, and lets users compare versions and roll back. BookStack lets administrators set abilities by role and override permissions at the shelf, book, chapter or page level, which helps limit who can edit approved threat models. The organization confirms access roles and retention settings. The step closes when a test threat model shows a complete change history and restricted editing rights.
Connect threat models to the code review workflow
DeployOpen links the design review step to the repository workflow so that new features affecting entry points or access levels trigger a threat model update before code is written or merged. Protected branches in GitLab Community Edition can restrict who pushes or merges, block direct pushes and keep force pushes disabled, which supports a documented gate. Where Semgrep Community Edition is used in CI/CD, it complements design review but does not replace it. The organization confirms the gate and its exceptions. The step closes when a sample change shows the threat model reference in the merge record.
Run and record the first threat modeling sessions
Trained reviewers from the organization, supported by DeployOpen, run threat modeling sessions for the highest-risk in-scope applications first. Each session records the design, entry points, access levels, threats, ratings and decisions in the agreed template, and the outcome is reviewed by the application owner. Sessions produce open items that feed the normal development backlog. The step closes when each in-scope application has a dated, approved threat model with a named reviewer and owner sign-off.
Prepare the evidence pack for the independent assessor
DeployOpen assembles an evidence pack that maps each in-scope application to its inventory entry, its threat model, its version history, its review approvals and its open items, so the assessor can test the Compliance metric in the Assessment Specification. The organization reviews the pack for accuracy and decides what to share. DeployOpen does not issue reports, attestations or certifications. An independent assessor or certification body performs any formal assessment and issues its own conclusions. The step closes when the organization holds a complete, reviewable evidence set and has confirmed it owns the resulting control statements.
