ISO/IEC 27001 Gap Analysis
ISO/IEC 27001:2022 defines requirements for an Information Security Management System (ISMS). ISO/IEC 27005:2022 elaborates the risk-management lifecycle underneath Clauses 6.1 and 8. Ten Factor Governance is an architectural model for making governance operable.
They are complementary rather than interchangeable: Ten Factor aligns strongly with the operational spine—requirement → risk → control → policy → evaluation → evidence → enforcement → audit—while the outer management-system envelope (context, leadership, objectives, competence, Statement of Applicability, management review, CAPA) and richer ISO/IEC 27005 risk-assessment semantics remain the largest gaps. Proposed management-system objects are stubbed under ISO/IEC 27001 Definitions.
Coverage labels:
- Full = direct corresponding capability (not by itself ISO conformity);
- Partial = useful machinery exists but an ISO-required element is missing;
- Conceptual = the principle or schema could host the concern but has no first-class semantics for it;
- Does not cover / Not represented = no material direct representation. Encoding an Annex A topic as a Control alone is Conceptual, not Full—structured assets, schedules, tests and evidence are what move coverage up.
Requirement descriptions below are concise paraphrases of public ISO material, not a substitute for a licensed copy of the standard.
ISO/IEC 27005 risk overlay
ISO/IEC 27005 supports ISO/IEC 27001 implementation and supplies detail for risk assessment and treatment. The rows below are the additional risk-management concerns that should sit under Clauses 6.1 and 8.
5.1Risk-management process
PartialDefine a coherent information-security risk process.
Incomplete relative to ISO: Ten Factor does not define a complete risk-process instance. Add RiskAssessment/process metadata.
Address: Ten Factor does not define a complete risk-process instance. Add RiskAssessment/process metadata.
5.2Risk-management cycles
FullRisk management is repeated as context and systems change.
Review triggers/cadence and risk-history links are not represented.
Add review triggers/cadence and risk-history links.
6.1Organisational considerations
PartialEstablish business/organisational context for risk.
Missing: GovernanceContext: internal/external issues, objectives, jurisdictions, dependencies.
Add GovernanceContext: internal/external issues, objectives, jurisdictions, dependencies.
6.2Interested-party requirements
ConceptualIdentify stakeholder and external requirements.
Incomplete relative to ISO: InterestedParty + Obligation/requirement references.
Address: InterestedParty + Obligation/requirement references.
6.3Applying risk assessment
PartialDefine where/how assessment applies.
Incomplete relative to ISO: explicit assessment scope, trigger and subject needed.
Address: explicit assessment scope, trigger and subject needed.
6.4Risk criteria
ConceptualEstablish and maintain criteria against which risk is measured/evaluated.
Missing: versioned RiskCriteria, scale, thresholds and method.
Add versioned RiskCriteria, scale, thresholds and method.
6.4.2Risk-acceptance criteria
PartialState when risk can be retained and under whose authority.
Incomplete relative to ISO: acceptance authority, threshold, expiry and approval evidence.
Address: acceptance authority, threshold, expiry and approval evidence.
6.4.3Assessment criteria
PartialMake assessments repeatable and comparable.
Incomplete relative to ISO: assessment methodology/version is not first-class.
Address: assessment methodology/version is not first-class.
6.5Appropriate method
ConceptualChoose and document a risk-assessment method appropriate to context.
Incomplete relative to ISO: assessment-method, methodology/version/reference fields.
Address: assessment-method, methodology/version/reference fields.
7.2Risk identification
PartialIdentify and describe risks systematically.
Missing: explicit risk scenario, source/event and affected resource.
Add explicit risk scenario, source/event and affected resource.
7.2.2Risk owners
FullAssign ownership.
Needs clarification: risk owner versus artefact owner/approver.
Clarify risk owner versus artefact owner/approver.
7.3.2Consequences
PartialAssess potential consequences/impact.
Incomplete relative to ISO: explicit consequence dimensions and pre/post-control values.
Address: explicit consequence dimensions and pre/post-control values.
7.3.3Likelihood
Does not coverAssess likelihood.
No direct factor mapping.
Missing: likelihood scale/value/rationale.
Add likelihood scale/value/rationale.
7.3.4Risk level
ConceptualCombine analysis into a risk level.
Does not distinguish inherent/current/residual level.
Distinguish inherent/current/residual level.
7.4Risk evaluation
PartialCompare analysis with criteria and prioritise treatment.
Missing formal criterion comparison and disposition.
Add formal criterion comparison and disposition.
8.2Treatment options
PartialDecide whether/how to modify, retain, avoid or otherwise address risk.
Incomplete relative to ISO: structured treatment-option vocabulary, target risk and due date.
Address: structured treatment-option vocabulary, target risk and due date.
8.3Necessary controls
Partial–FullDerive controls from risk treatment, not merely from a checklist.
Incomplete relative to ISO: make treats-risk relationship canonical rather than merely a mapping convention.
Address: make treats-risk relationship canonical rather than merely a mapping convention.
8.4Compare with Annex A
PartialCheck chosen controls against the reference set so none necessary are overlooked.
Incomplete relative to ISO: iSO profile/catalogue can close this without core-schema changes.
Address: iSO profile/catalogue can close this without core-schema changes.
8.5Statement of Applicability
PartialRecord applicable controls, implementation status and justification for inclusion/exclusion.
Missing: generic ApplicabilityProfile; this is one of the clearest gaps.
Add generic ApplicabilityProfile; this is one of the clearest gaps.
8.6Treatment plan
PartialPlan actions, owners, approval and residual-risk disposition.
Incomplete relative to ISO: treatment action, due date, target risk, dependencies and status.
Address: treatment action, due date, target risk, dependencies and status.
8.6.2Risk-owner approval
PartialRisk owner approves treatment.
Incomplete relative to ISO: signed/versioned approval event.
Address: signed/versioned approval event.
8.6.3Residual-risk acceptance
PartialExplicitly accept remaining risk.
Incomplete relative to ISO: first-class residual risk value, accepting authority, time limit/review trigger.
Address: first-class residual risk value, accepting authority, time limit/review trigger.
9Risk operation
PartialActually execute assessment and treatment processes.
Incomplete relative to ISO: explicit risk-assessment execution log would tighten provenance.
Address: explicit risk-assessment execution log would tighten provenance.
10.3Communication/consultation
Conceptual/PartialCommunicate risk with appropriate stakeholders.
Incomplete relative to ISO: CommunicationPlan/consultation record.
Address: CommunicationPlan/consultation record.
10.4Documented information
PartialRetain process and result information.
Retention, approval, distribution and authoritative-record controls.
Retention, approval, distribution and authoritative-record controls.
10.5Monitoring/review
Partial–FullMonitor changes in factors influencing risk and reassess.
Risk-specific trigger/review event is missing.
Risk-specific trigger/review event is missing.
10.6Management review
ConceptualManagement reviews risk management within ISMS governance.
Missing: ManagementReview.
Add ManagementReview.
10.7Corrective action
PartialCorrect failures and causes.
Missing: root cause, systemic issue, effectiveness test and closure.
Add root cause, systemic issue, effectiveness test and closure.
10.8Continual improvement
Full conceptuallyImprove the management/risk process using results and change.
Incomplete relative to ISO: explicit feedback edges from review/action to changed risk/control/policy.
Address: explicit feedback edges from review/action to changed risk/control/policy.
Clause 4 — Context of the organisation
4.1Organisation and its context
PartialUnderstand internal/external issues relevant to the ISMS.
Activity/dependency context exists, but not organisational context as a governed object.
GovernanceContext ( internal-issues, external-issues, objectives, jurisdictions ); clarify Govern Sensitive Activities scope can include governance/management activities.
4.2Interested parties
ConceptualIdentify relevant stakeholders and their information-security requirements.
Obligations can be guidance, but stakeholder/requirement provenance is absent.
InterestedParty/Obligation records; expand Govern Dependencies from dependencies to dependency and obligation sources.
4.3ISMS scope
PartialDetermine organisational and technical boundaries/applicability of the ISMS.
Governance Twin is intentionally scoped to an activity, not an enterprise ISMS boundary.
GovernanceScope ( organisations, locations, systems, activities, exclusions, interfaces ).
4.4ISMS and processes
Conceptual/PartialEstablish, implement, maintain and improve the ISMS and interacting processes.
The governance pipeline is modelled; the management system itself is not.
Define an ISMSProfile/generic GovernanceSystem composed from existing artefacts.
Clause 5 — Leadership
5.1Leadership and commitment
PartialTop management must direct, support and integrate information-security governance.
Ownership is not equivalent to executive leadership commitment/accountability.
Extend Governance Has Owners to distinguish accountable-executive, artefact-owner, risk-owner, approver; reusable GovernanceRole.
5.2Information-security policy
PartialEstablish, maintain and communicate an appropriate security policy.
Strong policy-as-data architecture; weaker on executive approval, organisational communication and periodic policy review.
Approval/sign-off and review-cycle; communication/acknowledgement link.
5.3Roles, responsibilities and authorities
PartialAssign and communicate responsibility and authority for information security.
RACI appears in several artefacts but authority/delegation is fragmented.
Shared GovernanceRole ( responsible, accountable, consulted, authority, delegation, escalation ).
Clause 6 — Planning
ISO/IEC 27005 supplies the detailed interpretation of the risk-assessment and treatment concerns in these rows, including risk criteria, identification, consequence, likelihood, evaluation, treatments, control selection, SoA and residual-risk acceptance.
6.1.1Risks and opportunities — general
PartialDetermine risks/opportunities affecting ISMS outcomes and plan actions.
Security risk is supported; improvement opportunities are not a strong first-class concept.
ImprovementOpportunity or generic action/change proposal.
6.1.2Information-security risk assessment
PartialDefine and apply a repeatable assessment process using criteria and risk ownership.
Missing method, scenario, likelihood, criteria comparison and inherent/residual state.
Expand risk model as specified below.
6.1.3Risk treatment
PartialSelect treatments and controls, compare against Annex A, document applicability and accept residual risk.
Strong ingredients; no native SoA or complete treatment lifecycle.
ApplicabilityProfile + treatment/acceptance fields.
6.2Security objectives and planning
ConceptualDefine measurable security objectives, responsibilities, resources and means of evaluation.
Control assessment is not the same as management objective measurement.
ObjectiveMetric ( objective, target, measure, owner, frequency, result ).
6.3Planning changes
Partial–Full architecturallyPlan ISMS changes in a controlled manner.
Excellent fit for governance artefacts; organisational change-planning fields are absent.
Clarify Governance is Version Controlled explicitly applies to management-system changes, not only executable governance definitions.
Clause 7 — Support
7.1Resources
Does not cover/ConceptualDetermine/provide people, tools, time and other resources needed for the ISMS.
- Governance Has Owners only indirectly
Ownership does not establish resource sufficiency.
Optional ResourceRequirement; or treat this explicitly as out of scope, covered by an ISMS profile.
7.2Competence
Does not coverDetermine required competence, ensure it and retain evidence.
No direct factor mapping.
Major people-management gap.
CompetenceRecord ( role, required-skill, qualification, training, evidence, expiry ).
7.3Awareness
ConceptualEnsure relevant people understand policy, contribution and consequences.
- Governance Has Owners indirectly
Machine-readable policy does not prove awareness.
Training/acknowledgement evidence profile.
7.4Communication
Conceptual/PartialDefine what, when, with whom and how to communicate about the ISMS.
No communication plan or consultation trail.
CommunicationPlan or fields on GovernanceSystem.
7.5.1Documented information — general
Partial–FullMaintain required documentation and evidence.
Machine-readable/versioned records are a strong fit; formal document-management obligations go further.
Add record classification/retention references.
7.5.2Creating/updating documentation
PartialIdentify, format, review and approve information appropriately.
Version/author metadata is strong; approval state/signatory is weaker.
approved-by, approved-at, effective-from, supersedes.
7.5.3Control of documented information
PartialAvailability, protection, distribution, retention, change control and disposition.
Retention, access/distribution and disposal semantics are absent.
RecordPolicy ( retention, access, integrity, disposition, authoritative-source ).
Clause 8 — Operation
8.1Operational planning/control
Partial–Full architecturallyPlan, establish criteria for, control and evidence ISMS/security processes and outsourced processes.
One of the best alignments; generic process/resource inventory is still missing.
Bind governance twins explicitly to GovernedResource/process identifiers.
8.2Operational risk assessment
PartialPerform assessments at planned intervals and after significant change.
Assessment execution exists more clearly for controls than risks.
RiskAssessmentLog or extend Risk Catalog with assessment history/triggers.
8.3Operational risk treatment
PartialImplement the treatment plan and retain results.
Enforcement is related but treatment execution is broader.
Treatment status/actions/evidence links.
Clause 9 — Performance evaluation
9.1Monitoring, measurement, analysis and evaluation
Partial–FullDecide what to monitor/measure, how/when, analyse results and evaluate ISMS performance/effectiveness.
Excellent control evaluation, but management-level objectives/KPIs are not first-class.
ObjectiveMetric; relate evaluation results to objectives and risks.
9.2Internal audit
PartialConduct planned, objective audits against requirements and retain results.
Audit artefact exists, but programme, independence/impartiality, auditor competence and scheduling are incomplete.
Extend AuditLog with programme, independence, auditor competence and follow-up references.
9.3Management review
ConceptualTop management periodically assesses suitability, adequacy and effectiveness and records decisions/actions.
A material management-system gap.
ManagementReview ( period, participants, inputs, risks, objectives, audits, changes, decisions, actions ).
Clause 10 — Improvement
10.1Continual improvement
Full conceptuallyContinually improve ISMS suitability, adequacy and effectiveness.
Ten Factor states the architectural principle strongly, but there is no explicit feedback/change object.
Add links result → improvement → changed-artifact; no new Ten Factor needed.
10.2Nonconformity and corrective action
PartialRespond to failure, correct it, determine causes/recurrence, implement action and test effectiveness.
Enforcement addresses response, but not the complete corrective-action lifecycle.
CorrectiveAction ( nonconformity, containment, root-cause, action, owner, due, effectiveness-test, closure ).
Annex A — Organisational controls
The 2022 organisational theme comprises A.5.1–A.5.37. Coverage below assesses whether Ten Factor natively addresses each control's subject, not merely whether a Control entry could be written for it.
A.5.1Policies for information security
Partial–FullEstablish, approve, communicate and review security policies.
Machine-readable/versioned policy is very strong; approval/communication/review needs strengthening.
Policy approval/review fields.
A.5.2Security roles and responsibilities
PartialDefine and allocate security responsibilities.
Roles distributed across artefacts.
Shared GovernanceRole.
A.5.3Segregation of duties
ConceptualSeparate conflicting responsibilities to reduce misuse/error.
No native conflict/SoD relation.
Optional conflicts-with/separation constraint in policy profile.
A.5.4Management responsibilities
PartialRequire personnel to follow security policy/procedures.
Accountability principle, but not workforce-management process.
Role/acknowledgement semantics.
A.5.5Contact with authorities
ConceptualMaintain appropriate regulatory/law-enforcement contacts.
No stakeholder/contact register.
InterestedParty.contact + trigger/procedure.
A.5.6Contact with special interest groups
ConceptualMaintain relevant professional/security information relationships.
External relationship not modelled.
InterestedParty/external source.
A.5.7Threat intelligence
PartialCollect and analyse threat information to inform security.
Threat catalogue is strong representation; intelligence-source/feed lifecycle is absent.
source, observed-at, confidence, indicator/ref, expiry fields.
A.5.8Security in project management
PartialIntegrate security into project governance/lifecycle.
Strong software-project story, less generic project governance.
Clarify Govern the Factory and the Product Separately applicability beyond software where appropriate.
A.5.9Inventory of information and associated assets
PartialInventory information/assets and assign ownership.
Ten Factor deliberately starts with activities rather than assets; ISO still needs the asset view.
AssetSystemCatalog / GovernedResource. Do not replace Govern Sensitive Activities's activity focus; link the two.
A.5.10Acceptable use of assets
Conceptual–PartialDefine acceptable handling/use of information/assets.
Policy can express usage rules; assets are not first-class.
GovernedResource + policy binding.
A.5.11Return of assets
ConceptualRecover organisational assets on employment/contract change.
Personnel and asset lifecycle absent.
Asset custody + people-lifecycle profile.
A.5.12Classification of information
PartialClassify information based on security needs.
No information inventory/classification lifecycle.
GovernedResource.classification, scheme/version.
A.5.13Labelling information
ConceptualApply labels consistent with classification scheme.
No native label semantics.
Classification/label fields in resource profile.
A.5.14Information transfer
Conceptual–PartialSecure transfer inside/outside organisation.
Transfer can be a sensitive activity, but data-flow/resource semantics are not modelled.
Governed activity/resource bindings; optional data-flow profile.
A.5.15Access control
PartialEstablish rules for physical/logical access based on business/security requirements.
Context In, Decisions Out's request/context/decision shape is highly relevant; IAM lifecycle remains external.
Standard authorisation decision profile.
A.5.16Identity management
ConceptualManage identity lifecycle.
No identity lifecycle schema.
Keep domain-specific; bind external IAM evidence to control.
A.5.17Authentication information
ConceptualSecure allocation/management of credentials/authentication secrets.
Control-testing substrate, not credential management.
No core addition required.
A.5.18Access rights
PartialProvision, review, modify and remove access rights.
Governance decision/evaluation fit well; rights inventory external.
Reference external entitlement/resource IDs and owner.
A.5.19Supplier security
Partial–FullManage security risks arising from suppliers.
Govern Dependencies directly addresses inherited dependency trust/risk; supplier entity and assurance record absent.
Dependency/Supplier profile under GovernedResource.
A.5.20Supplier agreements
Partial/ConceptualInclude appropriate security requirements in agreements.
Requirement composition fits; contracts/suppliers not first-class.
Obligation.source = contract; supplier binding.
A.5.21ICT supply-chain security
Partial–FullManage security through ICT supply chains.
Strong dependency/factory concepts; component provenance lives elsewhere.
Standard dependency identifiers/provenance refs rather than duplicating SBOM/SLSA.
A.5.22Supplier monitoring/review/change
PartialMonitor supplier security and manage changes.
Supplier target not native.
Supplier/resource target + reassessment trigger.
A.5.23Cloud-service security
Conceptual–PartialGovern acquisition, use, management and exit of cloud services.
General governance works; cloud lifecycle semantics are external.
Cloud profile/catalogue, not a new core schema.
A.5.24Incident-management planning/preparation
ConceptualEstablish incident process, roles and readiness.
No incident/case object or playbook execution record.
Incident/case integration or standard incident reference.
A.5.25Assessing/deciding on security events
PartialTriage events and decide whether they constitute incidents/actions.
Context In, Decisions Out's explicit context → decision model fits unusually well; incident semantics absent.
Incident decision profile (event, context, classification, reason, actor).
A.5.26Incident response
Conceptual–PartialRespond to incidents according to procedures.
Enforcement is not a full incident-response workflow.
Incident reference/action profile.
A.5.27Learning from incidents
PartialUse lessons to reduce recurrence and improve controls.
Feedback intent strong; root cause and improvement linkage absent.
CorrectiveAction + caused-change-to.
A.5.28Collection of evidence
Full architecturallyIdentify, collect and preserve evidence appropriately.
One of the strongest direct matches; forensic chain-of-custody may require domain extension.
Add optional custody/integrity signature semantics where required.
A.5.29Security during disruption
ConceptualMaintain appropriate security during disruption/crisis.
Continuity state/plans not represented.
Business-continuity profile/external plan reference.
A.5.30ICT readiness for business continuity
Conceptual–PartialEnsure ICT capabilities support continuity/recovery objectives.
Can test readiness; no BIA/RTO/RPO/recovery dependency model.
Optional resilience profile *(service,RTO,RPO,dependencies,test)**.
A.5.31Legal/statutory/regulatory/contractual requirements
PartialIdentify, maintain and comply with applicable obligations.
Requirements can be encoded and mapped very well; applicability/provenance/register semantics need strengthening.
A.5.32Intellectual-property rights
ConceptualProtect IP and respect relevant rights/licences.
No IP/licence inventory.
Domain profile/external licence identifiers; no core change.
A.5.33Protection of records
PartialProtect records against loss, destruction, falsification and unauthorised access.
Integrity/provenance strong conceptually; retention/disposal policy absent.
RecordPolicy.
A.5.34Privacy and PII
Conceptual–PartialMeet privacy/PII protection requirements.
Can import privacy obligations and controls; no privacy data/process semantics.
Separate privacy profile; bind data classification/obligations to activities.
A.5.35Independent review
PartialIndependently review security governance/implementation.
Audit object is strong, independence not sufficiently first-class.
Auditor role/independence fields.
A.5.36Compliance with security policies/rules/standards
Full architecturallyRegularly assess compliance.
Evaluation-to-control/evidence mapping is a direct fit; management response remains separate.
No major core addition; add ISO profile mappings.
A.5.37Documented operating procedures
PartialDocument operating procedures where needed and keep them current.
Good versioned governance; procedural/work-instruction semantics not special.
Treat procedures as Guidance/Policy subtype or linked artefact.
Annex A — People controls
A.6.1–A.6.8 is one of the clearest areas where the model is intentionally thin: Ten Factor concentrates on governance architecture and accountable activity ownership, not on personnel management.
A.6.1Screening
Does not coverPerform appropriate pre-employment/personnel screening.
No direct factor mapping.
No personnel/HR lifecycle.
Keep as HR profile/external system evidence; no need to burden the core model.
A.6.2Employment terms
ConceptualEmbed information-security responsibilities in employment terms.
- Governance Has Owners indirectly
Employment/contract semantics absent.
Obligation can reference employment agreement.
A.6.3Awareness, education and training
Does not cover/ConceptualEnsure appropriate security awareness and competence.
No direct factor mapping.
A real ISO management-system gap.
CompetenceRecord/training evidence.
A.6.4Disciplinary process
ConceptualEstablish a communicated disciplinary process for policy violation.
- Governance Has Owners indirectly
Enforcement here concerns governance non-compliance, not employment discipline.
HR profile/reference; avoid conflating the two.
A.6.5Responsibilities after termination/change
ConceptualMaintain/revoke relevant responsibilities and access on role/end-of-employment changes.
Identity/personnel lifecycle absent.
External HR/IAM references + evaluation evidence.
A.6.6Confidentiality/NDA
ConceptualIdentify, document and review confidentiality obligations.
Contract/person binding absent.
Obligation linked to actor/role.
A.6.7Remote working
Conceptual–PartialProtect information accessed/processed/stored while working remotely.
Context-aware policy helps but doesn't supply remote-work security controls itself.
Use contextual attributes in policy; ISO control catalogue/profile.
A.6.8Security-event reporting
ConceptualEnsure personnel report observed/suspected security events promptly.
No event/incident intake object.
Incident/event profile and reporting evidence.
Annex A — Physical controls
A.7.1–A.7.14: Ten Factor can treat activities such as entering secure areas or disposing of equipment as sensitive activities, but it does not currently model premises, rooms, physical assets, environmental hazards or facilities management directly.
A.7.1Physical security perimeters
ConceptualDefine/protect physical security boundaries.
No facility/perimeter entity.
GovernedResource may include facility/location; keep details domain-specific.
A.7.2Physical entry
Conceptual–PartialControl and monitor entry to secure areas.
Entry is an excellent sensitive-activity/decision example; physical access-system model external.
Contextual decision/evidence binding.
A.7.3Securing offices/rooms/facilities
ConceptualApply suitable physical safeguards to facilities.
No facility semantics.
Facility profile if needed.
A.7.4Physical security monitoring
Conceptual–PartialMonitor premises for unauthorised physical access.
Evidence/continuous monitoring patterns fit; sensor/physical event domain absent.
External evidence source references.
A.7.5Physical/environmental threats
Conceptual–PartialProtect premises/assets against environmental and physical threats.
Generic threats can represent the risk; locations/assets absent.
Governed-resource/facility binding.
A.7.6Working in secure areas
ConceptualControl practices while personnel operate in sensitive areas.
Activity-centric model fits, domain semantics external.
No core addition.
A.7.7Clear desk/clear screen
ConceptualReduce exposure of sensitive information in workspaces.
- Govern Sensitive Activities only broadly
No special support needed.
ISO control profile + assessment requirement.
A.7.8Equipment siting/protection
ConceptualProtect equipment through suitable placement and safeguards.
- Govern Dependencies broadly
Equipment inventory absent.
A.7.9Assets off-premises
ConceptualProtect organisational assets outside controlled premises.
Asset/location tracking absent.
Resource + contextual location.
A.7.10Storage media
ConceptualManage removable/storage media securely through lifecycle.
Media/asset lifecycle absent.
Resource lifecycle profile.
A.7.11Supporting utilities
Conceptual–PartialProtect against utility failures affecting processing facilities.
Govern Dependencies correctly frames utility dependence; topology/equipment details external.
Dependency from governed resource to utility.
A.7.12Cabling security
ConceptualProtect power/data cabling against interception/damage.
- Govern Dependencies broadly
Domain-specific implementation.
No core addition.
A.7.13Equipment maintenance
ConceptualMaintain equipment securely and reliably.
- Continuous Governance broadly
Equipment/work-order model absent.
External maintenance evidence link.
A.7.14Secure disposal/re-use
Conceptual–PartialRemove data/licensed software and securely dispose/re-use equipment.
Disposal can be governed/evidenced; asset lifecycle absent.
Resource lifecycle + disposal evidence.
Annex A — Technological controls
A.8.1–A.8.34 is where Ten Factor's software architecture perspective is most directly useful—factory vs product, context-in/decision-out, version-controlled governance, evidence and continuous governance.
A.8.1User endpoint devices
ConceptualProtect information processed/stored/accessed through endpoint devices.
Device-management semantics external.
Resource/device profile or external CMDB/MDM reference.
A.8.2Privileged access rights
Partial–Full architecturallyRestrict and govern privileged rights.
Privileged access is explicitly cited by Ten Factor as a sensitive governed activity; entitlement lifecycle remains external.
Standard privileged-access Governance Twin profile.
A.8.3Information access restriction
PartialEnforce information/application access according to policy.
Excellent decision architecture; not an IAM implementation.
Canonical decision receipt/evidence mapping.
A.8.4Access to source code
PartialRestrict/manage access to source code and related development assets.
Factory governance directly relevant; repository/IAM details external.
Factory profile + evidence from SCM.
A.8.5Secure authentication
Conceptual–PartialImplement authentication technologies/processes appropriate to restrictions.
Governance of decision, not authentication technology.
No core addition.
A.8.6Capacity management
Conceptual–PartialMonitor/adjust resources to meet current and expected capacity needs.
Continuous measurement fits; capacity model external.
Metrics/evidence through ObjectiveMetric.
A.8.7Malware protection
Conceptual–PartialPrevent/detect/recover from malware.
Strong assessment substrate but no malware-specific implementation.
External tooling evidence; ISO profile.
A.8.8Technical vulnerabilities
PartialObtain vulnerability information, assess exposure and remediate appropriately.
Strong lifecycle pieces; missing first-class vulnerability/resource construct.
Map external vulnerability IDs to resource/risk and enforcement action.
A.8.9Configuration management
Partial–Full architecturallyEstablish, implement, monitor and review secure configurations.
Versioned/tested governance is an excellent fit; actual configuration inventory external.
Reference configuration artefact/version in evidence.
A.8.10Information deletion
Conceptual–PartialDelete information when no longer required.
Deletion can be a governed/evidenced activity; data inventory/retention basis absent.
Resource retention/disposal fields.
A.8.11Data masking
ConceptualApply masking according to access/business requirements.
- Context In, Decisions Out broadly
Data-policy implementation external.
Data classification/profile, not core schema.
A.8.12Data leakage prevention
Conceptual–PartialDetect/prevent unauthorised disclosure/exfiltration of sensitive information.
Can model risks/controls/evidence; DLP domain external.
External evidence/alert mappings.
A.8.13Information backup
Conceptual–PartialMaintain/test backups according to business/security needs.
Testing fits; backup inventory/schedule/restore objective absent.
Resilience profile with RPO/RTO/test evidence.
A.8.14Redundancy of processing facilities
Conceptual–PartialProvide sufficient redundancy to meet availability requirements.
Dependency risk fits; topology/resource redundancy external.
Governed-resource dependency profile.
A.8.15Logging
Partial–Full architecturallyGenerate, protect, store and analyse relevant logs.
Evidence-by-default is directly aligned; operational security logging requirements go beyond governance receipts.
Distinguish governance decision/evidence logs from application/security telemetry.
A.8.16Monitoring activities
PartialMonitor networks/systems/apps for anomalous behaviour and investigate.
Continuous governance is closely aligned; telemetry/anomaly mechanics external.
Event/incident link.
A.8.17Clock synchronisation
ConceptualSynchronise clocks to approved time sources.
- Evidence by Default indirectly
Important evidence prerequisite but no special semantics.
No core addition; assessment requirement suffices.
A.8.18Privileged utility programs
PartialRestrict/control utilities capable of overriding controls.
Use of utility can be a governed activity.
Privileged-action activity profile.
A.8.19Software installation on operational systems
Partial–Full architecturallyControl software installation in production.
Release/install governance is a core Ten Factor use case.
Factory/product deployment profile and evidence.
A.8.20Network security
ConceptualSecure/manage network devices and networks.
Network topology/configuration is outside current models.
External architecture/resource references.
A.8.21Network-service security
Conceptual–PartialDefine/manage security characteristics and service levels of network services.
Dependency/service obligations fit; service entity absent.
GovernedResource service/dependency.
A.8.22Network segregation
ConceptualSegregate networks according to security requirements.
- Govern Dependencies broadly
Domain-specific architecture control.
No core addition.
A.8.23Web filtering
ConceptualManage access to external websites to reduce exposure.
- Context In, Decisions Out broadly
Generic policy decision pattern, not web-security model.
No core addition.
A.8.24Cryptography
ConceptualEstablish rules for appropriate cryptographic controls and key management.
- Governance is Version Controlled broadly
Cryptographic/key-management semantics absent.
Domain-specific control catalogue/evidence.
A.8.25Secure development lifecycle
Full architecturallyIntegrate security throughout system/software development lifecycle.
Ten Factor has an unusually strong fit; specific secure-SDLC practices still come from controls/guidance.
Publish a secure-factory profile rather than add a factor.
A.8.26Application-security requirements
PartialIdentify/approve security requirements when developing/acquiring applications.
Governance Twin gives requirements a machine-readable home; application requirement schema is external.
Bind controls/guidance to implementation-twin component IDs.
A.8.27Secure architecture/engineering principles
PartialEstablish and apply security engineering principles.
Architectural governance strong; architecture itself needs another model/tool.
Link to architecture-as-code identifiers rather than duplicating them.
A.8.28Secure coding
PartialApply secure coding principles/practices.
Factory and continuous evaluation fit; coding standard/tooling external.
Secure-factory profile with SAST/code-review evidence references.
A.8.29Security testing in development/acceptance
Partial–Full architecturallyDefine and perform security testing before acceptance/release.
Assessment requirements/results are a particularly good match; exact testing technique external.
No major core addition.
A.8.30Outsourced development
PartialGovern security of externally developed systems/software.
Strong factory/dependency architecture; supplier entity/contract requirements absent.
Supplier/dependency profile.
A.8.31Separation of development, test and production
Partial–Full architecturallySeparate and appropriately secure development/test/production environments.
Ten Factor explicitly expects promotion through environments and distinguishes factory/product concerns.
Environment IDs/scopes in Governance Twin implementation binding.
A.8.32Change management
Partial–Full architecturallySubject information-processing changes to controlled change procedures.
Review/version/test/promote is almost exactly the desired governance pattern.
Add approval/effective-version provenance to common metadata.
A.8.33Test information
ConceptualSelect/protect/manage test information appropriately.
Data-management semantics external.
Data/test-environment profile only if needed.
A.8.34Protection during audit testing
Conceptual–PartialEnsure audit tests do not adversely affect operational systems/processes.
Audit exists, but test-safety/authorisation isn't specifically modelled.
Audit plan fields for target, constraints, approval and permitted techniques.
Synthesis
Across clauses and Annex A, Ten Factor often has the right architectural principle but not the domain object, and it lacks the management-system and asset semantics ISO expects. The framework should not reimplement all 93 Annex A domains as core schemas—cryptography, malware protection, web filtering, physical perimeters and screening belong as ISO-derived control/catalogue content plus integrations to specialist evidence sources.
ISO/IEC 27001/27005 validates much of the architectural direction behind Ten Factor. The strongest matches are activity/risk focus, Governance Twins binding guidance–risk–control–policy to implementation, versioned change, continuous evidence and assurance, dependency governance, and ownership/Party Register.
The substantive omissions are the organisation governing governance—context and interested parties; ISMS scope; leadership and authority; objectives and metrics; competence and communication; formal applicability (SoA); management review; and complete corrective-action/continual-improvement records—plus richer ISO/IEC 27005 assessment and treatment semantics.
The right response is extension, not redesign. Highest-value generic additions, now stubbed as definitions:
- GovernanceContext / GovernanceScope
- GovernedResourceCatalog
- richer RiskAssessment (criteria, method, scenario, consequence, likelihood, residual)
- ApplicabilityProfile (Statement of Applicability)
- ObjectiveMetric
- ManagementReview
- CorrectiveAction
CompetenceRecord, CommunicationPlan, Incident, supplier and business-continuity structures are useful as profiles or external referenced schemas rather than core primitives. Ten Factor needs principally clarifications—management-system activities, evidence lifecycle, management feedback, obligation dependencies and differentiated ownership (risk owner vs treatment owner vs residual-risk acceptance authority vs auditor)—not an eleventh factor.
The intended division of labour:
- ISO/IEC 27001 — what organisational information-security management system must exist
- ISO/IEC 27005 — how its risk-management machinery should work
- Ten Factor Governance — what architectural properties make that governance operable