fix(soa): allow editing of remote-applicable iso 27001 section 7 controls

[tofikwest]

Problem

Statement of Applicability locks all ISO 27001 §7 (physical security) controls to "Not Applicable" for remote orgs, preventing edits. But some §7 controls genuinely apply to remote companies like clear desk policies for home workstations, off-premises asset security, and secure equipment disposal. Users can't mark these as applicable even though they should be audit-relevant.

Root cause

The remote org detection blankets the entire §7 section with a lock. The logic treats all physical security controls as inapplicable for fully-remote orgs, but controls 7.7, 7.9, 7.10, and 7.14 deal with endpoint security and offboarding rather than on-premises facilities.

Fix

Narrow the auto-lock to only premises-bound controls (7.1 7.6, 7.8, 7.11 7.13). Leave endpoint and off-premises controls (7.7, 7.9, 7.10, 7.14) editable. Updated the control classification check in the SoA service to distinguish between physical premises and remote-applicable controls. Screen and PDF export remain in sync.

Explicitly NOT touched

• The remote org detection itself
• Controls outside §7
• The PDF export logic (kept in sync with screen state)

Verification

✅ Remote org §7 premise controls (7.1 7.6, 7.8, 7.11 7.13) remain locked
✅ Remote-applicable controls (7.7, 7.9, 7.10, 7.14) are now editable
✅ Edit icons appear for previously locked rows
✅ PDF export matches screen state
✅ Non-remote orgs unaffected

Fixes CS-749

---

Summary by cubic

Make ISO 27001 §7 controls editable for fully remote orgs by using “Not Applicable” as a fallback only when unanswered, and honoring saved answers in both the UI and export. Addresses Linear CS-749: Unable to edit “no” response on SoA.

• Bug Fixes
  • Removed the edit lock on §7 for fully remote orgs; the edit icon now appears.
  • Applied a remote default: 7.x controls default to Not Applicable only if there’s no saved answer; saved answers take precedence.
  • Kept UI and PDF export in sync by using the same defaulting logic on both sides.
  • Simplified props in EditableSOAFields and centralized defaulting in resolveSoaDisplay and the API.
  • Added tests for display, export, and table row editability to prevent regressions.

^{Written for commit 644a808. Summary will update on new commits.}

[linear]

CS-749

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
app	Ready	Preview, Comment	Jul 16, 2026 8:55pm
comp-framework-editor	Ready	Preview, Comment	Jul 16, 2026 8:55pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
portal	Skipped		Jul 16, 2026 8:55pm

[tofikwest]

@cubic-dev-ai review it

[cubic-dev-ai]

@cubic-dev-ai review it

@tofikwest I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

cubic analysis

1 issue found across 8 files

Confidence score: 3/5

• In apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/components/soa-display.ts, the isControl7 logic appears to match all 7.* controls, which can incorrectly render unanswered 7.7/7.9/7.10/7.14 as “Not Applicable” for remote orgs instead of applying the normal default; merging as-is risks misleading compliance status in the SoA UI. Narrow the isControl7 condition to only the intended controls and add a regression check for those unanswered cases before merging.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/components/soa-display.ts">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/components/soa-display.ts:63">
P2: According to linked Linear issue CS-749, remote orgs with no answer for 7.7, 7.9, 7.10, or 7.14 still display as Not Applicable instead of receiving the normal default. `isControl7` includes every `7.*` closure; limit this fallback to the premises-bound control set.</violation>
</file>

Linked issue analysis

Linked issue: CS-749: [BUG] Unable to edit "no" response on SoA

Status	Acceptance criteria	Notes
✅	Previously locked §7 rows that should be editable (remote-applicable controls like 7.7, 7.9, 7.10, 7.14) show an edit action and can be edited	UI locking that previously prevented editing was removed and a unit test was added asserting the edit button is present for a fully-remote physical-security question.
✅	Saved answers for 7.x controls are honored in the export (export matches the on-screen SoA instead of force-locking saved answers to Not Applicable)	Service export logic now prefers a persisted answer over the remote default and a unit test verifies an existing saved answer is preserved in the generated export.
✅	Unanswered premises-bound 7.x controls default to Not Applicable for fully-remote orgs (UI and export) when there is no saved answer	Both the client display and server export apply the remote default only when there is no saved answer; a new test covers the export fallback.
✅	PDF export stays in sync with the on-screen SoA (same defaulting/answering rules applied)	The export uses the same remote-defaulting logic as the screen and tests mock the generated PDF payload to assert the passed questions reflect the same justification and applicability.
⚠️	Non-remote organizations' §7 controls are unaffected by the remote defaulting changes	The code paths are gated by an isFullyRemote check, so non-remote orgs should be unaffected, but there is no explicit new unit test shown that asserts non-remote behavior remains identical.
❌	Premises-bound §7 controls remain edit-locked (cannot be edited) for fully remote orgs	The PR description/verification claims premise-bound controls remain locked, but the UI change removed the isControl7+isFullyRemote disable logic and tests assert an edit action for a physical-security row. The diff shows defaulting for unanswered controls, but no UI lock enforcement.

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: According to linked Linear issue CS-749, remote orgs with no answer for 7.7, 7.9, 7.10, or 7.14 still display as Not Applicable instead of receiving the normal default. isControl7 includes every 7.* closure; limit this fallback to the premises-bound control set.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/components/soa-display.ts, line 63:

<comment>According to linked Linear issue CS-749, remote orgs with no answer for 7.7, 7.9, 7.10, or 7.14 still display as Not Applicable instead of receiving the normal default. `isControl7` includes every `7.*` closure; limit this fallback to the premises-bound control set.</comment>

<file context>
@@ -68,6 +57,16 @@ export function resolveSoaDisplay({
+  // No saved answer yet: a fully remote org's physical-security (7.x) controls
+  // default to Not Applicable. This is only a default — any saved answer above
+  // wins and the field stays editable. The export applies the identical fallback.
+  if (isFullyRemote && isControl7) {
+    return {
+      displayIsApplicable: false,
</file context>

[tofikwest]

@cubic-dev-ai review it

[cubic-dev-ai]

@cubic-dev-ai review it

@tofikwest I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

cubic analysis

No issues found across 8 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

Linked issue analysis

Linked issue: CS-749: [BUG] Unable to edit "no" response on SoA

Status	Acceptance criteria	Notes
✅	Previously locked §7 “No” answers become editable (edit icon appears) so users can change ‘Not Applicable’ responses.	UI locking for 7.x controls was removed and the table/mobile row now render the editable field; a unit test asserts the Edit action is present for a 7.x question on a fully-remote org.
✅	Saved answers for §7 controls are honored in the SOA export/PDF and match the on-screen SoA (saved Applicable/Not Applicable not overwritten by remote default).	Export logic was changed to prefer persisted answers over a remote default; service-spec tests assert a saved 7.x answer is preserved in the generated export.
✅	Unanswered physical-security (7.x) controls default to Not Applicable for fully remote orgs (remote rationale is used only when no saved answer exists).	Both the display resolution and export now apply the remote justification only when there is no saved answer; tests verify the defaulting behavior for unanswered controls.

_{Re-trigger cubic}

[claudfuen]

🎉 This PR is included in version 3.104.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀