What “Security-by-Design” Actually Means: Coderio’s ISO 27001-Aligned Software Development Framework.

Every software development vendor now claims security by design. The phrase appears on capability decks, in RFP responses, and beside a certification badge in the footer. Almost none of those claims survive one specific question: what changes in your engineering process on day one of an engagement, and who is accountable when it does not happen?

That gap matters more than it used to. The IBM and Ponemon Institute Cost of a Data Breach Report 2026 puts the global average cost of a breach at 4.99 million US dollars, a 12% year-over-year increase and a record high, driven by rising detection, escalation, and lost business costs. When an outsourced team holds commit access to your repositories and credentials to your staging environment, your vendor’s engineering habits are part of your attack surface. Not adjacent to it. Part of it.

This article covers what security by design means as a delivery methodology rather than a marketing position: the framework Coderio uses, how it maps to ISO/IEC 27001:2022 control families, and where it deliberately stops. The order matters. The practices came first, and the certification verifies them. A certificate that arrives before the practice is an audit result, not an engineering culture, and the difference shows up in production.

Key takeaways

1. Security-by-design is a claim about sequence, not tooling. Security constraints either enter as inputs to design or arrive later as findings against it.
2. A certificate cannot distinguish a policy document from an engineering habit. Only delivery behavior can.
3. Coderio organizes the work into five control planes: engagement boundary, design-time threat modeling, build-time verification, runtime and data boundary, and evidence and continuity. They fail independently, so they are governed separately.
4. The highest-value control for most organizations is the least glamorous: named individual identities, task-scoped access, enforced offboarding.
5. ISO/IEC 27001 alignment verifies that a practice is a system. It does not create the practice, and the order in which the two arrive determines software quality.

Security by design in software development, defined

Security by design is an approach in which security requirements are treated as design constraints from the first architectural decision, rather than as defects found and remediated later. It is a claim about when security enters the process and who owns it, not about which tools are installed.

The principles it draws on are old and stable. Two come straight from Saltzer and Schroeder’s 1975 paper, The Protection of Information in Computer Systems — least privilege and fail-safe defaults — two more descend from it, and the rest are later additions to the same tradition:

1. Least privilege. Every user, service, and process gets the minimum access its task needs, no more.
2. Defense in depth. No single control is load-bearing; compromise of one layer does not grant the system.
3. Secure defaults. The out-of-the-box configuration is the safe one. Security is not an operator opt-in.
4. Fail securely. When a check errors or a dependency is unavailable, the system denies rather than permits.
5. Minimize the attack surface. Every endpoint, port, dependency, and permission is a liability that must justify itself.
6. Separation of duties. No actor can both perform and approve a sensitive action.
7. Complete mediation. Every access to every object is checked for authority, not just the first one in a session or the first one in a request chain.

These are uncontroversial. Nearly every vendor claiming security by design would endorse all six, which is exactly why endorsement is not evidence. The distinguishing question is mechanical: what in the delivery process forces these principles onto a specific feature, on a specific day, by the engineer writing it?

The vendor security questionnaire problem

Most enterprise buyers assess vendor security through a questionnaire: two hundred rows in a spreadsheet, answered once, filed, revisited at renewal. It measures whether a policy exists, not whether engineers behave differently because of it.

A vendor can answer yes to “do you perform code review” with a policy PDF and zero enforcement in the pipeline. Yes to “do you conduct threat modeling” because one architect ran one session in 2023. Yes to “do you restrict access on the principle of least privilege” while every developer shares an administrator credential for the client’s cloud tenant, because provisioning individual roles was slower during onboarding and nobody fixed it.

None of those are lies exactly. They are true statements about documents. A questionnaire cannot distinguish a document from a habit, which is why questionnaire-passing vendors still ship insecure software. The same mechanism degrades code quality in outsourced software development, with lower consequences.

Security-by-design versus security-as-a-phase

The conventional model treats security as a late-stage gate: requirements, design, build, test, security review, release. A penetration test lands two weeks before launch, findings arrive as a report, and the team triages them against a deadline already committed to the market.

The economics are brutal. An authorization flaw found in design review costs a conversation. The same flaw found in a pre-launch penetration test costs a refactor of every endpoint that inherited the pattern. Remediation costs differ by orders of magnitude because the design has propagated.

Security-by-design inverts the sequence. Constraints are inputs to design rather than findings against it. This is what shift-left security means when it is more than a slogan, and the practical consequences are concrete:

Dimension	Security-as-a-phase	Security-by-design
When security is considered	After the architecture is fixed, usually before release	Before the architecture is fixed, as a design constraint
Primary artifact	A findings report	A threat model and a set of enforced pipeline gates
Who owns it	A security team or an external tester	The engineers writing the code, with specialist support
Cost of a finding	Refactor plus schedule renegotiation	A design decision, made once
Effect on velocity	Sharp late-stage stalls	Slightly slower start, fewer unplanned stops
Evidence produced	Point-in-time report, stale on arrival	Continuous, queryable delivery record

Note the velocity row. Security by design is not free, and any vendor claiming it costs nothing is describing something else. It front-loads effort: threat modeling a payments flow costs a day a team without the practice would spend writing code. What it buys is avoiding the six-week late-stage stall that determines whether a release ships on the promised date. That trade is sharpening. The 2025 DORA report found that, unlike the year before, AI adoption now has a positive relationship with delivery throughput — but “AI adoption does continue to have a negative relationship with software delivery stability.” DORA’s explanation is the argument for this entire plane: without robust control systems, an increase in change volume leads to instability. More change reaches the late gate than the gate can inspect.

Why the certificate follows the practice

ISO/IEC 27001:2022 specifies requirements for an information security management system. Annex A lists 93 controls in four themes: organizational, people, physical, and technological. An external auditor examines whether the management system exists, whether applicable controls are implemented, and whether the organization can demonstrate it operates them consistently.

That last clause carries the weight. Certification does not audit the elegance of a security architecture. It audits whether an organization does, repeatably and with evidence, what it says. There are two ways to get there.

1. Build the practices first, then document what you already do and invite an auditor to verify it. The audit is a confirmation exercise, and findings are minor and procedural, because the behavior was already consistent.
2. Decide you need a certificate, hire a consultancy to write a management system, train staff to answer audit questions, and pass. The documents describe a target state. Behavior converges slowly, or not at all.

Both paths produce the same certificate. They produce very different software. Coderio took the first, and that is the whole point of this article: the certification certifies what we were already doing, because the standard we built to was enterprise-grade delivery, not audit readiness.

This is not a claim that certification is unimportant; it is a procurement necessity and, for regulated buyers, non-negotiable. It is a claim about causality. A management system built to pass an audit optimizes for evidence production. One built from delivery practice produces evidence as a byproduct of working correctly, and only the second survives the auditor leaving the building.

The same reasoning applies to the other frameworks worth aligning to. NIST’s Secure Software Development Framework, SP 800-218, published as SSDF version 1.1 in February 2022, exists because, as its abstract states, few software development lifecycle models explicitly address software security in detail. It is a set of practices, not a checklist. OWASP SAMM is explicitly technology and process-agnostic and risk-driven, built on the premise that no single recipe works for every organization. Frameworks that describe themselves that way invite engineering judgment, not compliance theater. CISA makes the same argument at the policy level. Its Secure by Design guidance, jointly sealed with international partners, rests on three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top. All three assign the burden to the manufacturer rather than the customer.

The Coderio delivery framework: five control planes

DORA’s summary of its 2025 findings applies exactly here: “AI doesn’t fix a team; it amplifies what’s already there.” The same is true of security practice. A framework does not create discipline — it makes the discipline you already have enforceable, and the discipline you lack visible.

Each plane has a distinct owner, failure mode, and enforcement mechanism. We separate them because they fail independently: a team can have excellent build-time verification and catastrophic access hygiene, and the second breaches you regardless of the first. The same five planes structure our security-by-design engineering practice across every engagement.

Plane 1: Engagement boundary

This plane governs how a Coderio team enters a client environment and what it can reach inside. It comes first because most vendor-originated incidents begin here, and it’s the plane most often compromised by onboarding schedule pressure.

The controls we hold ourselves to:

1. Named individual identities only. Every engineer gets a distinct account in every client system. No shared credentials, no team accounts, no service account used interactively. This control is most often waived during a rushed kickoff.
2. Role-scoped access derived from the actual task. A backend engineer on a payments integration does not get read access to the customer database. Requests specify system, scope, reason, and expiry date.
3. Time-bound elevation. Production access, where granted at all, is temporary, requested per incident, logged, and revoked automatically. Standing production access for a vendor engineer is a finding, not a convenience.
4. Offboarding as a delivery task with an owner. When an engineer rolls off, credential revocation is a ticket with a named assignee and a same-day service level, not an email to whoever remembers. Orphaned vendor credentials are how an engagement that ended two years ago becomes a breach vector today.
5. Documented data residency posture. Which jurisdictions hold which data, and who can reach it. For clients with regulatory exposure, we treat data sovereignty and regional cloud strategy as an architecture input, not a legal footnote.

Plane 1 reads as obvious, and it is the plane we learned most painfully. Early in our enterprise work, we offboarded by convention rather than tickets. It worked, until an access review turned up credentials still active weeks after an engineer had rolled off a finished engagement. Nothing was exploited, but the gap existed because nobody owned closing it. That is when revocation became a ticketed task with a named assignee and a same-day service level. Every control here exists because the convention version failed first.

Plane 2: Design-time threat modeling

This plane produces the constraints that shape architecture. It runs before implementation, and its output is a document the implementing engineers actually read.

We threat model at the feature level, not the system level, because system-level models age into wall decoration. The Threat Modeling Manifesto frames the exercise as four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. At feature scope, we make the second question concrete with a narrower set: what data crosses this boundary, who is authorized to cross it, what happens when authorization fails, and what an attacker gains by controlling either side. Teams preferring a formal taxonomy can run STRIDE against the same boundary and reach similar conclusions. The methodology matters less than whether the session happens before the code does.

For a new endpoint exposing customer transaction history, that forces decisions on object-level authorization, whether identifiers can be enumerated, rate limiting, what the error response reveals, and what lands in the log. Those five decisions, made in an hour before the endpoint exists, prevent the most common classes in the OWASP Top 10 from ever being written. After it ships, each change has a blast radius.

The verification target for this plane is the OWASP Application Security Verification Standard, which gives a level-appropriate requirement set rather than a generic aspiration. A marketing site and a clearing system are not the same risk tier, and pretending otherwise wastes effort or leaves a critical path unguarded.

Clear module boundaries make authorization enforceable at a small number of chokepoints, which is why we treat strategic outsourcing with clean architecture as a security practice, not just a maintainability one. A system where authorization logic is duplicated across 40 controllers will eventually have 39 correct implementations.

Plane 3: Build-time verification

This plane is where security stops depending on individual diligence. Everything in it is automated, runs on every change, and can block a merge. A control a developer in a hurry can skip is not a control.

The scale of that problem is now measurable. In the same DORA research, 90% of developers report using AI at work and more than 80% say it has increased their productivity — while 30% report little or no trust in the code it generates. That is a large volume of change entering the pipeline from a source its own authors do not fully trust. Advisory tooling does not survive contact with it.

The standing pipeline configuration:

1. Static analysis on every pull request, with the ruleset tuned to the stack rather than left at vendor defaults. Untuned analysis produces noise, teams learn to dismiss it, and the tool becomes worse than absent because it manufactures false assurance.
2. Dependency and transitive dependency scanning, with severity thresholds that block rather than warn. Most modern applications are mostly other people’s code, and the dependency tree is where that becomes exploitable.
3. Secret detection pre-commit and in CI. Both, because pre-commit hooks are locally disableable and CI is not.
4. Build provenance for anything we ship. A generated software bill of materials and a signed record of how the artifact was produced, following the SLSA build track levels. Regulated buyers increasingly require this, and retrofitting provenance onto a pipeline never instrumented for it is a rebuild, not a configuration change — which is why we treat supply chain hardening as pipeline work, not a procurement exercise.
5. Infrastructure-as-code scanning before apply. A permissive storage bucket policy is a one-line change that reaches production faster than any application vulnerability, and orchestration configuration deserves the same treatment, which is why we cover Kubernetes for developers as a security topic.
6. Automated regression coverage on security-relevant paths. Authentication, authorization, and session handling get tests that fail loudly. Autonomous regression testing makes this economically viable at the change velocity modern teams operate at.
7. Human review with a security-specific checklist for changes touching authentication, authorization, payments, or personal data. Automation catches known patterns. A reviewer catches the design mistake no rule encodes.

None of this works without the surrounding culture, the argument in no process, no success, and in our approach to DevOps best practices. A gate a team resents is a gate a team routes around.

Plane 4: Runtime and data boundary

Code that was secure at merge runs in an environment that changes without it. This plane covers what happens after deployment.

The core assumption is that network location confers no trust. A request from inside the cluster is authenticated and authorized identically to one from the public internet, the operational content of zero trust security once the vendor language is stripped out. For AI-bearing systems, the same principle extends to model access paths and training data, which we cover in applying AI and ML to zero trust architecture.

Data handling is where regulated clients concentrate their attention, correctly. Classification determines encryption, retention, access, and logging. Personal data is minimized at collection, not filtered at query time. Non-production environments get masked or synthetic data, never a production copy, because every exception ever granted became permanent.

Detection is the last element: instrumented authentication failures, privilege changes, and anomalous data access, routed to alerts a human sees. Security orchestration and automation matters in proportion to alert volume, because past a threshold, unautomated response means undetected incidents. This is where our digital security studio does the runtime work. IBM puts the gap at 1.93 million US dollars in savings for organizations that use AI and automation in security versus those that don’t. Where AI components are in the stack, the security risks specific to AI systems need their own controls, since prompt injection and model extraction do not resemble what an application firewall was built for. The IBM 2026 report records a 56% increase in AI-driven attacks, mostly deepfake impersonation and AI-enabled malware. One in four malicious breaches is now AI-enabled, and those breaches cost 6 million US dollars on average — a million more than the global average.

Plane 5: Evidence and continuity

The fifth plane produces the record. Not primarily for auditors, though it satisfies them, but for the client, so posture is a queryable fact.

Per engagement, we maintain a current access register with justification and expiry; threat models versioned alongside the features they cover; pipeline gate configuration and change history; scan and test results with remediation status and dates; incident records including near misses; and a change log for security infrastructure.

The near-miss record is the one most vendors omit and the one that reveals the most. A company that logs the vulnerability caught in review, before it merged, is measuring its own process. An empty near-miss log means it is either extraordinary or not looking.

This plane is also what makes compliance testing a reporting exercise rather than a fire drill. When evidence accumulates continuously, an audit is a query. When it does not, an audit is three weeks of reconstruction, which is where organizations discover what they were not actually doing.

How the planes map to ISO/IEC 27001:2022 Annex A controls

The mapping below is illustrative, not a statement of scope. The correspondence is high because both describe competent practice, arrived at independently.

Control plane	Primary Annex A controls	What an auditor examines
Engagement boundary	5.15 Access control · 5.16 Identity management · 5.18 Access rights · 6.5 Responsibilities after termination · 8.2 Privileged access rights · 8.4 Access to source code	Access provisioning records, offboarding evidence, screening and agreements
Design-time threat modeling	5.8 Information security in project management · 8.25 Secure development life cycle · 8.26 Application security requirements · 8.27 Secure architecture and engineering principles	Secure development policy, documented security requirements in design
Build-time verification	8.8 Management of technical vulnerabilities · 8.28 Secure coding · 8.29 Security testing in development and acceptance · 8.31 Separation of development, test and production · 8.32 Change management	Change management, secure coding, separation of environments, testing records
Runtime and data boundary	5.12 Classification of information · 8.11 Data masking · 8.15 Logging · 8.16 Monitoring activities · 8.22 Segregation of networks · 8.24 Use of cryptography	Cryptography, logging and monitoring, data masking, network controls
Evidence and continuity	5.22 Monitoring and review of supplier services · 5.27 Learning from information security incidents · 5.28 Collection of evidence · 5.35 Independent review · 5.37 Documented operating procedures	Documented information, internal audit, corrective action, supplier management

One control sits across all five planes rather than inside any of them. A.8.30, Outsourced development, requires an organization to direct, monitor and review the activity of development it outsources. It is written for the buyer, not the vendor — which means that when you engage us, our delivery record becomes evidence in your audit. That is the practical reason our fifth plane exists in the form it does: the access register, the versioned threat models, the gate configuration history and the remediation dates are not artifacts we keep for ourselves. They are what makes your A.8.30 obligation demonstrable without three weeks of reconstruction.

One honest note. No vendor implements all 93 Annex A controls in every engagement, and any vendor claiming otherwise is describing a statement of applicability they have not read. Applicability is set by risk assessment, so the right question is which controls a vendor excluded and on what documented basis.

What this looks like in the first two weeks

Framework descriptions are easy to agree with and hard to verify. Here is the shape of a Coderio engagement start: a US healthcare technology company adding a scheduling and eligibility integration, five engineers, protected health information in scope.

Days 1 to 3. No repository access yet. We run a data flow session with the client’s engineering lead and produce a classification map: which fields are protected health information, where they enter, where they persist, and which third parties touch them. Then we set the ASVS level and the regulatory constraints. We wrote about HIPAA and FERPA differences because a wrong assumption here propagates into every later design decision.

Days 5 to 8. Threat model for the eligibility integration. In a real instance of this pattern the session produced four constraints before any code existed: eligibility responses cached with a hard time-to-live rather than indefinitely, member identifiers tokenized at the integration boundary, error responses returning a generic failure rather than distinguishing “member not found” from “coverage inactive” because that distinction is an enumeration oracle, and audit logging of every check with the requesting user identity. The fourth was a compliance requirement. The third would have shipped as a vulnerability under any process reviewing security after implementation.

Days 8 to 12. Pipeline configuration before the first feature commit: static analysis tuned to the stack, dependency scanning with a blocking threshold, secret detection at commit and in CI, infrastructure-as-code scanning, and a review checklist for paths handling protected health information. The team writes production code in the second week rather than the first, and the API integration work proceeds against fixed constraints instead of discovering them.

That is four to six engineer-days of front-loaded cost on a five-person team. The comparison is not against zero. It is against the alternative: the enumeration oracle ships, is found by an assessor or a customer, and is remediated across every endpoint that copied the pattern, under deadline, with coordinated client-side changes.

Three failure modes we design against

Each maps to a principle from the list above that was endorsed and never enforced.

1. Authorization by convention (complete mediation). Authentication is checked rigorously; authorization is casual. Every request proves who the user is; few prove the user may act on the object referenced. It survives testing, where developers request their own records, and fails the first time someone increments an identifier in a URL. The fix is one enforcement chokepoint for object-level authorization, established before the second endpoint exists. Retrofitting it later means reconstructing the correct rule per resource from business logic nobody wrote down.
2. The trusted internal network (defense in depth). Services inside the perimeter call each other unauthenticated because they are inside the perimeter, so compromise of any component grants everything. Decomposition amplifies it, because internal trust relationships multiply faster than anyone tracks them. One reason we argue for restraint in monolith versus microservices decisions: every boundary added must be secured, monitored, and reasoned about.
3. Security debt as a permanent parking lot. Findings are logged, prioritized, and never resolved, each individually deferrable, until the aggregate is unassessable and the organization cannot state its own risk position. The control is a remediation service level tied to severity that blocks new feature work above a threshold. Blunt, unpopular, and the only version that works, because softer variants lose every prioritization argument they enter. Same dynamic as modernization as a posture rather than a project.

When security-by-design is the wrong investment

An honest framework states its limits. Some engagements don’t call for the full apparatus described above, and a vendor who cannot say so is selling rather than advising.

1. Genuine throwaway prototypes. Validating a hypothesis with synthetic data, no real users, and a hard commitment to discard the code. Threat modeling something that will be deleted in six weeks is a waste. The condition is the discard commitment, honored far less often than it is made. Prototypes that acquire real users have to be rebuilt, not hardened.
2. Static content with no data collection. A brochure site with no forms, no authentication, and no user data needs platform hygiene and dependency currency, not a threat modeling program.
3. Internal tools with no sensitive data and no external surface. A dashboard reading a public dataset for authenticated employees does not warrant the rigor of a payments path. Uniform rigor across unequal risk teaches teams that the rigor is arbitrary.
4. Components with a real decommission date. Hardening a system being retired next quarter, where risk is contained, and the window is short, is often less valuable than accelerating the replacement. That depends entirely on whether the date is real, and in legacy modernization work it frequently is not.

One clarification. None of these exemptions touch the engagement boundary plane: access hygiene is unconditional, because a credential on a low-value system is still a credential inside your environment. And tiering is not skipping. Tiering is a documented decision; skipping means nobody decided.

How to audit a vendor’s security-by-design claim

These work whether or not you are evaluating Coderio. Each is hard to answer without the practice behind it, and each has a recognizable evasion.

1. Show me a threat model from a recent engagement, redacted. Real ones are specific, dated, and reference named components. The evasion is a template or a generic diagram.
2. What blocks a merge in your default pipeline configuration, and who can override it? Real answers name tools, thresholds, and an override path with an approver. The evasion is a list of tools without enforcement semantics.
3. How long between an engineer rolling off and their credentials being revoked, and how do you know? Real answers cite a service level and the record that proves it. The evasion is “immediately,” with no measurement.
4. Describe a design decision in the last quarter where security constrained the architecture, and what it cost. Real answers are immediate and detailed. The evasion is a philosophy statement.
5. What is in your near-miss log for the last 90 days? Real answers exist. An empty log means the process is not being measured.
6. Who on the delivery team is accountable for security outcomes, and what happens if they are not met? Real answers name a role inside the delivery team. The evasion points to a separate security department the delivery team does not report to.

Weight answers by specificity, not confidence. A vendor describing a real practice volunteers its limitations. These belong alongside the commercial criteria in choosing the right software outsourcing partner and the CTO outsourcing playbook.

What certification actually certifies

ISO/IEC 27001 certification tells a buyer three things reliably and nothing else: a documented information security management system exists; an independent auditor examined a defined scope and found the applicable controls implemented; and the organization can produce evidence that it operates them consistently.

It is verification by a party with no incentive to flatter, which is more than a questionnaire provides. What it does not tell a buyer: whether the engineers on your account will threat model your feature, whether your gates are configured before the first commit or after the third sprint, whether your access is scoped to task or granted broadly for convenience. Those are delivery behaviors. Certification makes them likelier by requiring a system that produces them, but treating a certificate as a guarantee is the same category error as treating a questionnaire as a control.

Which is why the sequence matters. We built the framework because enterprise clients in regulated sectors demanded it, and because insecure software is a poor engineering outcome regardless of who demands what. The certification came afterward, and what it certifies is the practice that was already there. Done the other way around, the certificate would look identical on a capability deck, and the software would be worse. That is the entire content of the phrase security by design, and why it is worth interrogating every time a vendor uses it, including this one.

Frequently asked questions

1. Is security-by-design the same as DevSecOps?

They overlap but are not identical. DevSecOps describes integrating security tooling and responsibility into the delivery pipeline, which maps to the build-time verification plane. Security by design is broader, and its distinguishing element is design-time work: threat modeling and requirements that shape architecture before implementation. A team can have mature DevSecOps automation and still build an authorization model that no amount of scanning will fix, because static analysis cannot detect a missing requirement.

2. Does ISO 27001 certification mean a vendor’s code is secure?

No, and the standard does not claim to. ISO/IEC 27001 certifies an information security management system within a defined scope, verifying that the organization implements and consistently operates the controls it determined applicable. It does not assess the security of any particular application. Ask for the scope statement and the statement of applicability, then ask the delivery-behavior questions listed above.

3. How much does security-by-design add to project cost?

The cost concentrates at engagement start: four to six engineer-days on a five-person team for classification, threat modeling, and pipeline configuration. Ongoing cost is lower, mostly security-focused review on sensitive paths. The comparison that matters is against late-stage remediation, where the same defect costs a refactor plus schedule renegotiation instead of a design decision.

4. Can a nearshore or offshore team really deliver this?

Location is not the determining variable. Enforcement is. A distributed team with named individual identities, blocking pipeline gates, and a maintained access register has a stronger posture than a co-located team with shared credentials and advisory linting. Time zone overlap does help, because access reviews and threat modeling sessions work better live than asynchronously.

5. How is security by design different from secure by default, shift-left, and privacy by design?

Secure by default is one principle within security by design: the shipped configuration should be the safe one, with no operator opt-in. Shift-left describes the timing change, though it often means moving tools earlier rather than decisions earlier. Privacy by design is the parallel discipline for personal data, and it carries a legal obligation under GDPR Article 25, which requires data protection by design and by default. In practice, the two converge, because most privacy controls are implemented as security controls: minimization at collection, access scoping, retention limits, audit logging.

6. How do we retrofit this onto a system already in production?

In sequence, not at once. Establish engagement boundary controls first, because they are independent of the codebase. Add build-time gates next, in warn mode and then blocking, so the team sees existing debt before being penalized for it. Threat model prospectively, on new features, rather than modeling the whole existing system. Address the existing surface through scheduled assessment and a remediation service level.

The bottom line

Security-by-design is a claim about sequence. Constraints either enter the process as design inputs or arrive later as findings against it, and everything else follows from that choice.

ISO/IEC 27001 alignment verifies that this is a system rather than a set of good intentions, examined by someone with no reason to be generous. That verification is worth having, and we sought it deliberately. But we didn’t build the framework to pass an audit. We built it because enterprise software in regulated sectors cannot be delivered any other way. The audit found what was already there.

If you are evaluating a development partner, ask the six questions. Ask them of us. The answers should be specific and include the inconvenient parts.

If you would rather see the practice than hear about it, our Tech Health Check is a four-week architectural audit that produces the same kind of artifact this article argues for: prioritized findings, dated, with an owner against each one.