@rasensio/aidlc-content 1.78.0 → 1.80.0

package/docs/hygiene-and-compliance.md

@@ -84,6 +84,32 @@ The false-positive side is a deliberate trade. The pattern now flags `localhost.
 than a regular expression — and a control that misses a real host is worse than one that asks about
 an unusual alias.
 
+## SSAE 16, SSAE 18, SOC 1 and SOC 2
+
+People ask for "SSAE 16" when they mean SOC 1. SSAE 16 is the AICPA standard auditors followed to
+issue SOC 1 reports. It replaced SAS 70 in 2011 and was itself replaced by SSAE 18 in May 2017, so
+nobody issues an SSAE 16 report any more. SOC 1 covers controls that matter to a customer's
+financial reporting — billing, payroll, payments. SOC 2 is a different report, against the Trust
+Services Criteria. Both are issued under SSAE 18 today.
+
+SOC 1 has no fixed criteria. The company being audited writes its own control objectives, so there
+is no SOC 1 pack and none is planned, and the SOC 2 pack does not cover any company's SOC 1 control
+objectives. What it can do is show where its trail produces evidence related to the IT general
+controls a SOC 1 auditor usually tests:
+
+| IT general control area | SOC 2 pack controls | What the pack does not cover |
+|---|---|---|
+| Program changes | CC8.1 (evidenced) | Who can deploy to production, and that developers cannot. Changes made outside the lifecycle, including emergency fixes. |
+| Program development | CC8.1 (evidenced) | Data conversion, choosing a vendor package, and sign-off by the business before go-live. |
+| Logical access | CC6.1 (checked-only) | Granting, reviewing and removing user access: CC6.2 and CC6.3 are excluded as organizational. CC6.1 checks code paths for an authorization decision only. |
+| Computer operations | CC7.1 (checked-only), CC7.2 (checked-only) | Job scheduling, backups and restores, and incident response (CC7.3 and CC7.4 are excluded). |
+
+Point a SOC 1 auditor at the evidenced rows. A checked-only row records that a check was applied
+while the code was written, never that a control operated. Installing the SOC 2 pack does not make
+a project ready for a SOC 1 examination; it gives you a change-control trail to show when the
+control objectives you wrote ask for one. In `aidlc init` and `aidlc compliance list` the SOC 2
+pack is shown as "also asked for as SOC 1, SSAE 16" for this reason.
+
 ## How to use it
 
 ```

package/docs/lifecycle.md

@@ -86,8 +86,9 @@ Two gates are worth knowing because they block real work:
   This one has an override, and the honest observation from the retrospectives is that having the
   override meant it got waved through by reflex on every phase.
 
-`aidlc menu`, or bare `aidlc`, opens a picker of the common commands if you would rather not
-remember them.
+Bare `aidlc`, or `aidlc menu`, opens the console if you would rather not remember the commands:
+`/help` lists them, `/doctor` runs one, plain words go to your agent, and autopilot changes print
+as they happen.
 
 **When requirements move after their phase closed**, `aidlc amend <instance>` is the way back. The
 gates check that artifacts exist, not that they still agree with each other, so editing

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rasensio/aidlc-content",
-  "version": "1.78.0",
+  "version": "1.80.0",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/packs/soc2/pack.yaml

@@ -16,6 +16,16 @@ entitlement: unrestricted
 # someone editing the statement out.
 reviewed_by: null
 
+# "SSAE 16" is the retired name of the standard behind SOC 1 reports, and buyers
+# still ask for it. SOC 1 has no fixed criteria, so there is no SOC 1 pack; this one
+# is where such a request starts, because its CC8.1 trail is the change-control
+# evidence a SOC 1 auditor tests. The names are shown in the init wizard and by
+# `aidlc compliance list`; docs/hygiene-and-compliance.md explains the mapping and
+# what it does not cover (ssae-soc1-mapping/AC-6).
+asked_for_as:
+  - SOC 1
+  - SSAE 16
+
 layers:
   - name: soc2-constraints
     file: soc2-constraints.md