Part 046 — Authorization, Data Isolation, Audit Evidence, Non-Repudiation, and Regulatory Defensibility

Positioning

CPQ dan Quote-to-Order memproses keputusan bernilai tinggi:

• customer eligibility;
• price and discount;
• margin exception;
• approval;
• proposal presentation;
• acceptance;
• Agreement;
• Order change;
• Product activation;
• Billing activation;
• cancellation;
• and correction.

Ketika terjadi dispute, audit, incident, atau regulatory review, organisasi harus dapat menjawab:

• siapa melakukan apa;
• terhadap object dan version mana;
• dengan authority apa;
• menggunakan rules/configuration apa;
• evidence apa yang dilihat;
• keputusan apa yang dihasilkan;
• dan apakah data tenant/customer tetap terlindungi.

Core thesis: security dan auditability adalah domain capability. Authentication saja tidak cukup. Sistem membutuhkan object-level authorization, field sensitivity, decision provenance, immutable evidence, controlled administrative action, retention, privacy, and verifiable lifecycle history.

1. Security Objectives

Core objectives:

• confidentiality;
• integrity;
• availability;
• authenticity;
• accountability;
• non-repudiation;
• privacy;
• and resilience.

2. Confidentiality

Only authorized subjects can access information.

3. Integrity

Data and decisions cannot be altered without authorization/detection.

4. Availability

Authorized users/processes can access capability when needed.

5. Authenticity

Identity and source are genuine.

6. Accountability

Actions can be attributed to a subject/system.

7. Non-Repudiation

Evidence supports that a party/system performed or accepted an action.

Legal strength depends on implementation and jurisdiction.

8. Privacy

Personal data is processed according to purpose, minimization, and policy.

9. Resilience

System maintains or restores security properties under failure/attack.

10. Threat Actors

Possible actors:

• external attacker;
• malicious tenant user;
• compromised employee;
• over-privileged support/admin;
• compromised service account;
• malicious extension;
• and accidental operator.

11. Assets

High-value assets include:

• customer data;
• pricing and discounts;
• cost/margin;
• approval authority;
• proposal documents;
• acceptance evidence;
• Agreement terms;
• Product/Order state;
• Billing data;
• credentials;
• and audit records.

12. Trust Boundary

Every transition between:

• browser;
• API gateway;
• service;
• event broker;
• database;
• extension;
• partner;
• and support tooling

is a trust boundary.

13. Authentication

Establishes identity.

14. Human Authentication

Common mechanisms:

• OIDC;
• SSO;
• MFA;
• passkeys;
• certificate;
• or approved enterprise identity.

15. Service Authentication

Use:

• mTLS;
• workload identity;
• signed token;
• or managed service credentials.

16. Partner Authentication

May use:

• OAuth client credentials;
• mTLS;
• signed request;
• or API key with additional controls.

17. Authentication Context

May include:

• identity;
• tenant;
• organization;
• authentication strength;
• session;
• device;
• and risk.

18. MFA Requirement

High-risk actions may require step-up authentication.

19. Step-Up Authentication

Examples:

• accept high-value Offer;
• approve margin exception;
• export customer data;
• break-glass admin access.

20. Session Security

Consider:

• expiry;
• revocation;
• fixation;
• CSRF;
• device binding;
• and concurrent session policy.

21. Token Validation

Validate:

• issuer;
• audience;
• signature;
• expiry;
• nonce;
• scopes;
• and tenant.

22. Token Propagation

Avoid forwarding end-user token everywhere without audience control.

23. Identity Delegation

Service acts on behalf of user with clear actor and delegator.

24. Actor versus Effective Principal

Audit both:

• human/system initiating;
• service executing.

25. Impersonation

Support impersonation is high risk.

Prefer controlled delegated view/action with banner and audit.

26. Authorization

Determines whether authenticated subject can perform action.

27. Role-Based Access Control

Permissions assigned through roles.

28. Attribute-Based Access Control

Decision uses attributes:

• tenant;
• account;
• market;
• amount;
• resource state;
• user clearance;
• and channel.

29. Policy-Based Access Control

Central/embedded policy evaluates subject, action, resource, and context.

30. Relationship-Based Access Control

Access based on graph relationship:

• account manager of customer;
• member of opportunity team;
• approver for region.

31. Hybrid Authorization

Enterprise systems often combine RBAC, ABAC, and relationship rules.

32. Authorization Decision

Inputs:

subject
action
resource
resource state
tenant
context
policy version

33. Authorization Enforcement Point

API/service/domain command boundary.

34. Policy Decision Point

Evaluates policy.

35. Policy Information Point

Provides attributes.

36. Policy Administration Point

Manages policy lifecycle.

37. Domain Guard versus Security Policy

Domain guard asks whether action is valid.

Security asks whether actor may perform it.

Both are required.

38. Deny by Default

Unmatched authorization should deny.

39. Least Privilege

Grant minimum permissions and scope.

40. Separation of Duties

No one person should control conflicting high-risk steps.

41. Maker–Checker

One user requests; another approves.

42. Four-Eyes Principle

At least two independent authorized actors.

43. Self-Approval Prevention

Requester cannot approve own exception where policy prohibits.

44. Delegation

Approval authority may be delegated with:

• scope;
• period;
• limit;
• and audit.

45. Delegation Conflict

Overlapping/delegated authority must be deterministic.

46. Authority Limit

Examples:

• maximum discount;
• maximum contract value;
• market;
• product;
• and legal entity.

47. Approval Authority Snapshot

Decision should retain authority evidence/version at decision time.

48. Object-Level Authorization

Permission depends on specific resource.

49. Tenant-Level Authorization

Subject may operate only within allowed tenant.

50. Account-Level Authorization

Salesperson may access assigned customers/accounts.

51. Opportunity/Quote-Level Authorization

Collaboration team can view/edit specific Quote.

52. Product-Level Authorization

Operations may access installed Products by region/domain.

53. Field-Level Authorization

Different users see different fields.

54. Sensitive Fields

Examples:

• cost;
• margin;
• internal floor price;
• approval comments;
• personal data;
• tax ID;
• supplier cost;
• and security metadata.

55. Price Visibility

Customer sees offered price.

Sales may see list and negotiated price.

Finance may see cost/margin.

56. Margin Visibility

Restrict to authorized roles.

57. Cost Visibility

Often more restricted than price.

58. Approval Comment Visibility

Internal comments may not be customer-visible.

59. Proposal Visibility

Only published/authorized artifacts visible externally.

60. Field Masking

Return redacted/masked value.

61. Field Omission

Do not include unauthorized field.

62. Write Authorization

Field may be visible but not editable.

63. Derived Information Leakage

Even without cost field, discount/margin may be inferred.

Threat-model derived leakage.

64. Search Authorization

Search results and counts must enforce same permissions.

65. Export Authorization

Bulk exports are higher risk than single reads.

66. Report Authorization

Analytics/reporting must preserve tenant and field-level rules.

67. Cache Authorization

Never serve cached response across authorization context.

68. Event Authorization

Only authorized consumers access sensitive topics.

69. Support Authorization

Support role may need broader visibility but narrower mutation.

70. Administrative Authorization

Admin does not automatically mean unrestricted domain authority.

71. Break-Glass Access

Emergency access with:

• step-up auth;
• explicit reason;
• time limit;
• narrow scope;
• enhanced logging;
• and post-review.

72. Just-in-Time Access

Privilege granted temporarily after approval.

73. Privileged Access Management

Manage high-risk credentials and sessions.

74. Service Account Least Privilege

Each service gets only required actions/resources.

75. Secret Management

Store credentials in managed secret system.

76. Secret Rotation

Automated and non-disruptive.

77. Hard-Coded Secret

Never acceptable.

78. Credential Scope

Per environment, tenant, integration, and role where practical.

79. API Key

Use only with compensating controls; difficult user attribution.

80. mTLS

Provides service/partner identity and channel protection.

81. Authorization at Domain Command

Do not rely solely on gateway.

82. Defense in Depth

Enforce at:

• edge;
• service;
• repository/data policy;
• and downstream sensitive action.

83. Tenant Isolation

Security control at every layer.

84. Cross-Tenant IDOR

Insecure direct object reference using another tenant's ID.

85. IDOR Protection

Lookup must include authenticated tenant/authorization scope.

86. Enumeration Risk

Opaque IDs reduce but do not eliminate authorization need.

87. Cross-Tenant Cache Leak

Cache key omits tenant or authorization context.

88. Cross-Tenant Search Leak

Index filter omitted.

89. Cross-Tenant Event Leak

Topic ACL or consumer filter wrong.

90. Cross-Tenant Object Leak

Shared file/object URL not scoped.

91. Cross-Tenant Support Leak

Admin tooling global by default.

92. Tenant Isolation Test

Automated negative test across all access channels.

93. Data Classification

Classify data, for example:

• PUBLIC;
• INTERNAL;
• CONFIDENTIAL;
• RESTRICTED;
• REGULATED.

94. Classification Metadata

Apply to fields, documents, events, logs, and exports.

95. Personal Data

Examples:

• name;
• email;
• phone;
• address;
• identifiers;
• and behavioral data.

96. Financial Data

Price, invoice, tax, account, payment references.

97. Commercially Sensitive Data

Cost, margin, floor price, strategy, and supplier terms.

98. Security Data

Credentials, tokens, topology, vulnerabilities, and audit details.

99. Data Minimization

Collect and expose only what is needed.

100. Purpose Limitation

Use data only for declared/authorized purposes.

101. Data Retention

Keep data for defined operational, contractual, legal, and audit period.

102. Retention Policy

By:

• data category;
• tenant;
• jurisdiction;
• contract;
• and legal hold.

103. Retention Start

Could begin at:

• creation;
• termination;
• contract end;
• or case closure.

104. Deletion

Securely remove or anonymize after retention unless hold applies.

105. Legal Hold

Suspends deletion for specified evidence scope.

106. Hold Identity

Store:

• authority;
• scope;
• reason;
• start;
• and release.

107. Retention Conflict

Privacy deletion request may conflict with audit/legal obligation.

Route to governed process.

108. Data Subject Request

May include access, correction, deletion, or restriction depending policy/law.

109. Pseudonymization

Replace direct identifiers with token/reference.

110. Anonymization

Irreversibly remove identification capability.

Hard to guarantee; validate method.

111. Encryption at Rest

Protect persisted data.

112. Encryption in Transit

TLS/mTLS.

113. Field-Level Encryption

For highly sensitive values.

114. Tenant-Specific Keys

Stronger isolation and cryptographic erasure possibilities.

115. Key Management

Includes:

• generation;
• storage;
• rotation;
• backup;
• revocation;
• and access audit.

116. Key Loss Risk

Can make evidence/data unrecoverable.

117. Key Revocation

May be required after compromise or tenant termination.

118. Audit

Audit records security/business-relevant actions and decisions.

119. Audit Trail

Chronological evidence of lifecycle and changes.

120. Audit Event

Structured record, not only log line.

121. Audit versus Application Log

Audit

Evidence-oriented, durable, controlled.

Log

Operational diagnostic data, mutable retention/volume.

122. Audit versus Domain Event

Domain event communicates fact.

Audit record proves actor/context/change.

One transaction may generate both.

123. Audit Scope

Audit at least:

• authentication;
• authorization decision;
• sensitive read/export;
• create/update/delete/transition;
• approval;
• acceptance;
• administrative action;
• configuration;
• extension;
• and evidence access.

124. Read Audit

Not every read needs full audit, but sensitive records/exports often do.

125. Audit Record Fields

Representative:

auditId
actor
effectivePrincipal
tenant
action
resourceType
resourceId
resourceVersion
decision
reason
occurredAt
recordedAt
source
correlation
before/after reference

126. Actor

Human or workload identity.

127. Effective Principal

Identity on whose behalf action occurs.

128. Source Channel

UI, API, batch, migration, support, or system.

129. Resource Version

Exact version affected.

130. Action

Stable domain/security action code.

131. Decision

ALLOW, DENY, SUCCEEDED, FAILED, or outcome-specific.

132. Reason Code

Structured reason.

133. Before/After

Store full snapshots or references/diffs according to sensitivity and scale.

134. Semantic Diff

More useful than raw JSON for domain change.

135. Effective Time

When business effect applies.

136. Recorded Time

When evidence was written.

137. Correlation

Link across services/events/processes.

138. Causation

Link to triggering command/event.

139. Policy Version

Authorization/approval/rule version used.

140. Decision Inputs

For high-value decisions, retain relevant facts or immutable references.

141. Audit Immutability

Audit records should resist alteration/deletion.

142. Append-Only Storage

Common pattern.

143. WORM Storage

Write Once Read Many for high-assurance evidence where required.

144. Tamper Evidence

Use:

• hash;
• chained hash;
• signature;
• immutable storage;
• and restricted access.

145. Hash Chain

Each record includes prior hash.

146. Merkle Structure

Can prove set integrity efficiently.

147. Digital Signature

Provides origin/integrity evidence.

148. Trusted Timestamp

Can strengthen evidence timing.

149. Audit Encryption

Protect sensitive evidence.

150. Audit Access Control

Audit visibility itself is sensitive.

151. Audit Administrator Separation

Users who operate system should not freely alter audit.

152. Audit Retention

May differ from operational data retention.

153. Audit Export

Signed/controlled export with chain of custody.

154. Chain of Custody

Track evidence collection, transfer, access, and storage.

155. Evidence Package

A bundle supporting decision/dispute.

156. Evidence Package Contents

Possible:

• accepted proposal;
• Quote revision;
• price snapshot;
• approval decisions;
• Acceptance;
• Agreement;
• Order;
• audit timeline;
• and signatures/hashes.

157. Evidence Package Identity

Stable package ID and manifest.

158. Evidence Manifest

Lists artifacts, versions, hashes, and source.

159. Evidence Reproducibility

Reconstruct exact rendered/accepted commercial state.

160. Evidence Availability

Long-term readability requires format and storage strategy.

161. Evidence Redaction

Create authorized redacted view without altering original.

162. Audit Search

Search by:

• customer;
• Quote;
• Acceptance;
• Agreement;
• Order;
• Product;
• Billing charge;
• actor;
• and correlation.

163. Audit Query Authorization

Not all users can search all audit dimensions.

164. Traceability

Ability to follow identity and causation across lifecycle.

165. Horizontal Traceability

Across contexts:

Quote -> Acceptance -> Agreement -> Order -> Product -> Billing

166. Vertical Traceability

From business outcome to:

• rule;
• config;
• code/deployment;
• event;
• and infrastructure evidence.

167. Forward Trace

Source decision to downstream effects.

168. Backward Trace

Observed Product/charge back to accepted intent.

169. Lineage Identity

Use stable references at every boundary.

170. Traceability Graph

Nodes:

• artifacts;
• decisions;
• actions;
• events;
• states;
• and people/systems.

Edges:

• causedBy;
• derivedFrom;
• approvedBy;
• supersedes;
• fulfilledBy;
• billedBy.

171. Traceability Completeness

Every critical outcome has required upstream/downstream links.

172. Traceability Gap

Examples:

• Billing charge without accepted charge;
• Product without Order Item;
• approval without Quote revision;
• acceptance without proposal checksum.

173. Traceability Repair

Explicit administrative correction with evidence.

174. Decision Provenance

Explains why a decision occurred.

175. Pricing Provenance

Includes:

• input context;
• rule/version;
• components;
• adjustments;
• rounding;
• and snapshot.

176. Approval Provenance

Includes:

• policy;
• authority;
• evidence;
• revision;
• and decision.

177. Qualification Provenance

Includes:

• input;
• data source;
• result;
• validity;
• and explanation.

178. Order Transformation Provenance

Includes mapping and grouping versions.

179. Inventory Provenance

Includes Order Item and fulfillment outcome.

180. Billing Provenance

Includes accepted charge and Product/Agreement trigger.

181. Configuration Provenance

Includes tenant config, flags, overrides, and extensions.

182. Deployment Provenance

Which application/rule/schema version executed decision.

183. Defensibility

Ability to justify and demonstrate that outcome followed authorized rules and evidence.

184. Commercial Defensibility

Can prove:

• offered price;
• accepted scope;
• approval;
• and terms.

185. Operational Defensibility

Can prove:

• Order actions;
• fulfillment;
• Product state;
• and recovery.

186. Security Defensibility

Can prove:

• access was authorized;
• sensitive data protected;
• and admin actions controlled.

187. Regulatory Defensibility

Can produce required evidence, retention, and controls.

188. Dispute Defensibility

Can reconstruct customer-visible proposal and acceptance.

189. Non-Repudiation Evidence

Possible ingredients:

• authenticated identity;
• MFA/step-up;
• signed artifact;
• checksum;
• timestamp;
• nonce;
• and immutable audit.

190. Electronic Signature Boundary

Signature provider may own cryptographic/legal signature.

191. Signature Envelope

Store provider transaction/reference and signed document hash.

192. Acceptance Token

Bind acceptance to exact Offer/Proposal/version.

193. Replay Protection

Nonce/token consumed once.

194. Accepter Authority

Verify party/person authorized to accept.

195. Recorder versus Accepter

If salesperson records offline acceptance, distinguish recorder and actual accepter.

196. Multiple Signatories

Track each signer, role, sequence, and quorum.

197. Conditional Acceptance

Should not be misclassified as binding acceptance.

198. Evidence of Presentation

Prove what customer was shown.

199. Proposal Checksum

Bind acceptance to exact artifact.

200. Document Version

Immutable artifact version.

201. Document Retrieval

Historical artifacts remain accessible under retention.

202. Rendering Reproducibility

Prefer retaining generated artifact rather than relying solely on future re-render.

203. Audit for Approval

Capture:

• approver;
• authority;
• exact revision;
• requested exception;
• evidence;
• conditions;
• and decision time.

204. Conditional Approval

Conditions remain machine-readable and enforced.

205. Approval Expiry

Decision has validity period where applicable.

206. Reapproval

New revision/material change invalidates prior approval.

207. Audit for Order Change

Capture original, delta, assessment, approval, application, and outcome.

208. Audit for Cancellation

Capture scope, authority, effective date, downstream result, fee/credit, and residual.

209. Audit for Recovery

Capture incident/fallout, operator command, evidence, before/after, and reconciliation.

210. Security of Support Tools

Support tools are privileged applications.

211. Support Read Access

Scoped by tenant, case, role, and reason.

212. Support Write Access

Use explicit domain recovery commands.

213. Direct Database Access

Should be exceptional, controlled, and audited.

214. Database Archaeology Smell

Support needs ad hoc SQL to reconstruct lifecycle.

215. Support Session

Create case-linked privileged session.

216. Support Access Request

Includes:

• tenant;
• case;
• scope;
• duration;
• and approver.

217. Support Session Recording

Record commands/actions, not credentials.

218. Customer Notification of Access

May be contract/policy dependent.

219. Admin Action Preview

Show impact before execution.

220. Admin Action Approval

High-risk corrections need independent approval.

221. Bulk Admin Action

Needs per-item idempotency, dry run, canary, and result manifest.

222. Break-Glass Review

Post-event review mandatory.

223. Logging Security

Logs can leak:

• tokens;
• PII;
• prices;
• documents;
• and secrets.

224. Structured Logging

Log IDs and reason codes, not raw payload by default.

225. Log Redaction

Automated and tested.

226. Secret Detection

Scan source/build/log pipelines.

227. Trace Data Sensitivity

Spans may contain request parameters.

228. Metric Data Sensitivity

Tenant/customer labels can expose information.

229. Audit versus Observability Retention

Different purpose and retention.

230. Secure Error Handling

Do not expose stack, policy internals, or resource existence.

231. Enumeration-Safe Error

Cross-tenant/unauthorized lookup may return non-disclosing response.

232. Input Validation

Protect against:

• injection;
• malformed data;
• resource exhaustion;
• and unsafe files/templates.

233. Output Encoding

Prevent XSS/content injection in portal/proposal rendering.

234. Template Injection

Untrusted template/customization must be sandboxed.

235. File Upload Security

Validate:

• type;
• size;
• malware;
• storage;
• and access.

236. Document Download Security

Use short-lived authorized URLs or controlled streaming.

237. SSRF

Connectors/extensions must restrict outbound destinations.

238. SQL Injection

Use parameterized access and least privilege.

239. Mass Assignment

Reject fields not allowed for caller/operation.

240. Insecure Deserialization

Use safe schemas and type controls.

241. Event Poisoning

Validate producer identity and schema.

242. Replay Attack

Deduplicate signed callback/event and enforce timestamp/nonce.

243. Supply Chain Security

Protect source, build, dependencies, artifacts, and deployment.

244. Provenance Attestation

Record how artifact was built and signed.

245. Dependency Scanning

Identify vulnerabilities/licenses.

246. SBOM

Track components.

247. Artifact Signing

Verify images/packages/plugins.

248. Deployment Authorization

Only approved artifacts/configurations reach environment.

249. Change Management Evidence

Link code/config/schema deployment to approvals and incidents.

250. Environment Separation

Development/test data should not expose production customer data.

251. Synthetic Data

Use generated/sanitized data where possible.

252. Production Data Copy

Requires minimization, masking, approval, and retention.

253. Backup Security

Encryption, access control, restore testing.

254. Disaster Recovery Security

Failover must preserve identity, authorization, keys, and audit.

255. Incident Response

Security incident lifecycle:

• detect;
• contain;
• eradicate;
• recover;
• notify;
• and learn.

256. Incident Evidence

Preserve logs, audit, events, access, and affected resources.

257. Forensic Readiness

Design systems to collect evidence before incident occurs.

258. Time Synchronization

Accurate timestamps support correlation/evidence.

259. Clock Integrity

Monitor drift and trusted time source.

260. Security Event

Examples:

• AuthorizationDenied;
• BreakGlassAccessGranted;
• SensitiveExportCompleted;
• TenantIsolationViolationDetected;
• AuditIntegrityFailureDetected.

261. Security Event versus Audit

Security monitoring event can trigger alerts.

Audit remains evidence record.

262. SIEM Integration

Forward relevant security events with minimal sensitive payload.

263. Detection Rules

Examples:

• repeated cross-tenant access attempts;
• unusual bulk exports;
• approval by same requester;
• high-risk admin changes;
• and disabled audit pipeline.

264. Alert Severity

Based on security and business impact.

265. Audit Pipeline Failure

Fail behavior depends on action risk.

266. Fail Closed for Audit

Some high-risk actions should stop if mandatory evidence cannot be recorded.

267. Buffered Audit

Temporary durable local buffer can preserve availability.

268. Audit Backlog

Monitor and reconcile.

269. Audit Loss

A serious incident.

270. Audit Integrity Verification

Periodically verify hashes/signatures/storage controls.

271. Access Review

Periodic review of roles, service accounts, delegations, and support privileges.

272. Recertification

Managers/data owners confirm access need.

273. Dormant Account

Disable stale identities.

274. Orphan Service Account

No owning team.

275. Privilege Creep

Permissions accumulate over time.

276. Policy Drift

Authorization implementation differs between services.

277. Central Policy versus Local Enforcement

Central policy can improve consistency.

Local domain context still provides resource facts and enforces decision.

278. Policy Availability

Authorization dependency outage must have explicit fail behavior.

279. Cached Authorization

Risk of stale revocation.

Use short lifetime/version where high risk.

280. Revocation

Access removal should propagate promptly.

281. Authorization Decision Log

Record high-risk allow/deny with policy version and context.

282. Security Testing

Include:

• unit policy tests;
• integration authorization;
• negative tenant tests;
• abuse cases;
• and penetration testing.

283. Policy Test Matrix

Subject × action × resource × state × tenant × attributes.

284. Field-Level Test

Verify omission/masking/write denial.

285. Approval Abuse Test

Self-approval, delegation abuse, stale authority.

286. Acceptance Abuse Test

Replay token, wrong signer, expired Offer, altered artifact.

287. Admin Abuse Test

Break-glass, bulk change, impersonation.

288. Event Security Test

Unauthorized producer/consumer, replay, cross-tenant payload.

289. Audit Tamper Test

Attempt update/delete/reorder.

290. Evidence Reconstruction Test

Rebuild exact commercial decision package.

291. Retention Test

Delete/anonymize after period while respecting legal hold.

292. Key Rotation Test

Historical evidence remains accessible and verifiable.

293. Disaster Recovery Test

Audit and authorization remain correct after failover.

294. Security Metrics

• authentication failures;
• authorization denials;
• privilege changes;
• and sensitive exports.

295. Tenant Security Metrics

• cross-tenant attempts;
• isolation failures;
• and tenant-scoped incidents.

296. Audit Metrics

• events recorded;
• backlog;
• failed writes;
• integrity failures;
• and search latency.

297. Traceability Metrics

• missing source links;
• incomplete evidence packages;
• orphan Products/charges;
• and unknown actors.

298. Privileged Access Metrics

• break-glass uses;
• support sessions;
• JIT grants;
• and unreviewed sessions.

299. Approval Security Metrics

• self-approval attempts;
• authority violations;
• expired delegation;
• and stale approval reuse.

300. Privacy Metrics

• data subject requests;
• retention violations;
• and unauthorized sensitive access.

301. Security SLI

Examples:

• zero cross-tenant data exposure;
• all privileged actions fully audited;
• all accepted Offers have complete evidence package;
• all critical audit writes persisted;
• and all high-risk access reviewed within target.

Internal targets must be verified.

302. Audit Incident

Examples:

• missing Acceptance evidence;
• audit records mutable;
• duplicate actor identities;
• and broken correlation chain.

303. Security Incident

Examples:

• cross-tenant leak;
• over-privileged support;
• unsigned plugin;
• leaked proposal URL;
• and stale service credential.

304. Incident Containment

Possible:

• revoke token/key;
• disable integration/extension;
• block tenant/user;
• freeze evidence;
• stop exports;
• preserve logs;
• and notify required stakeholders.

305. Security Smells

• role checked only in UI;
• tenant ID trusted from request;
• admin equals unrestricted;
• and shared service account.

306. Audit Smells

• audit as text log;
• mutable audit table;
• no actor/effective principal;
• and no resource version.

307. Traceability Smells

• IDs copied in free text;
• no charge-to-Quote lineage;
• and no mapping/config version.

308. Evidence Smells

• proposal re-rendered later;
• signature reference missing;
• checksum absent;
• and timestamps inconsistent.

309. Privacy Smells

• full payloads in logs/events;
• indefinite retention;
• and production data in test.

310. Support Smells

• direct SQL repairs;
• global admin access;
• no case-linked session;
• and no post-review.

311. Anti-Patterns

Authentication Equals Authorization

Authenticated user may still be unauthorized.

Role-Only Authorization

Ignores tenant, object, amount, state, and relationship.

Audit as Debug Log

Evidence is incomplete and mutable.

Admin Can Do Anything

Breaks separation of duties and accountability.

Re-Render Evidence Later

Cannot prove what customer saw.

Hash without Source Control

Hash alone does not prove actor or authenticity.

Tenant Isolation by Application Convention

One missed check causes exposure.

Security after Domain Design

Critical authority and evidence semantics are lost.

312. Authorization Policy Template

## Action

## Subject / Role / Attributes

## Tenant / Resource Scope

## Resource State

## Authority Limits

## Separation of Duties

## Step-Up Authentication

## Decision / Deny Reason

## Policy Version

## Audit Requirements

313. Audit Record Template

Audit ID:
Actor:
Effective principal:
Tenant:
Action:
Resource/type/version:
Decision/outcome:
Reason:
Before/after:
Policy/rule/config version:
Occurred/recorded time:
Source/channel:
Correlation/causation:
Evidence references:

314. Evidence Package Template

## Evidence Package Identity

## Customer / Tenant / Transaction

## Quote / Revision / Price Snapshot

## Proposal Artifact / Checksum

## Approval Requests / Decisions

## Acceptance / Signatures / Authority

## Agreement

## Product Orders / Changes

## Product / Billing Outcomes

## Audit Timeline

## Artifact Manifest / Hashes

## Retention / Legal Hold

315. Data Classification Template

Data element:
Classification:
Owner:
Purpose:
Allowed roles/contexts:
Encryption:
Masking:
Logging:
Event/API exposure:
Retention:
Deletion/hold:

316. Privileged Access Template

Access request:
Actor:
Tenant/resource scope:
Reason/case:
Requested permissions:
Approver:
Start/expiry:
Step-up:
Session/action recording:
Post-review:

317. Traceability Link Template

From entity/version:
Relationship:
To entity/version:
Source:
Effective time:
Recorded time:
Evidence:
Correction/supersession:

318. Retention Template

Data/evidence category:
Retention start:
Duration:
Jurisdiction/tenant override:
Legal hold:
Archive:
Deletion/anonymization:
Verification:
Owner:

319. Security Invariants

Representative invariants:

• tenant and object authorization are enforced server-side;
• sensitive fields are exposed only to authorized roles/contexts;
• approval and acceptance bind exact immutable revisions/artifacts;
• privileged actions are time-bound and fully audited;
• audit evidence cannot be silently altered;
• every critical downstream Product/charge is traceable to accepted intent;
• security/configuration policy versions are retained with decisions;
• and privacy/retention actions preserve required legal evidence.

320. Worked Example: Margin Visibility

Sales user sees customer price and discount.

Finance approver sees cost/margin.

Customer sees neither cost nor internal approval evidence.

Same Quote resource uses field-level projection/authorization.

321. Worked Example: Approval Authority

Approver has authority up to 15% discount in Market A.

Decision records:

• authority policy version;
• Quote revision;
• discount;
• actor;
• and conditions.

322. Worked Example: Self-Approval Attempt

Requester tries to approve own exception.

Authorization/policy denies and audits attempt.

323. Worked Example: Acceptance Evidence

Customer accepts Proposal checksum X using signed session/token.

Acceptance binds:

• Offer;
• Proposal;
• signer;
• authority;
• time;
• nonce;
• and checksum.

324. Worked Example: Offline Acceptance

Salesperson records signed PDF.

System distinguishes:

• actual customer signer;
• employee recorder;
• document hash;
• and evidence source.

325. Worked Example: Support Repair

Support needs to link existing supplier Order after timeout.

JIT case-scoped access permits explicit LinkExistingExternalOrder command.

Before/after and reconciliation evidence are audited.

326. Worked Example: Break-Glass

Critical incident requires temporary Product correction permission.

Access expires in 30 minutes and requires post-review.

327. Worked Example: Cross-Tenant IDOR

User from Tenant A requests Quote ID from Tenant B.

Lookup enforces tenant/object relation and returns non-disclosing response.

Attempt is security-logged.

328. Worked Example: Sensitive Export

User exports 10,000 customer records.

Step-up authentication, export purpose, watermark, audit, and expiry apply.

329. Worked Example: Proposal URL Leak

A long-lived public object URL exposes proposal.

Fix:

• private storage;
• short-lived signed URL;
• authorization;
• download audit;
• and revocation.

330. Worked Example: Audit Integrity

Hash-chain verification detects missing/modified audit record.

Incident freezes evidence and investigates storage path.

331. Worked Example: Retention and Legal Hold

Terminated customer data reaches deletion date.

Active dispute legal hold preserves only required evidence scope.

Other eligible data is deleted/anonymized.

332. Worked Example: Billing Trace

Invoice line traces to:

• Billing Charge;
• Product;
• Product Order Item;
• accepted charge;
• Quote revision;
• and Agreement.

333. Worked Example: Rule Provenance

Customer challenges eligibility decision.

Evidence shows:

• input snapshot;
• qualification source;
• rule version;
• explanation;
• and decision time.

334. Worked Example: Plugin Compromise

Signed extension hash does not match approved artifact.

Platform blocks execution, revokes extension, and identifies affected transactions by version.

335. Worked Example: Audit Pipeline Outage

High-risk acceptance cannot persist mandatory evidence.

Policy fails closed or uses approved durable local buffer according to design.

Backlog is reconciled after recovery.

336. Worked Example: Production Data in Test

A copied database contains customer PII.

Incident response removes data, investigates access, and replaces process with sanitized/synthetic datasets.

337. Senior Engineer Operating Model

Model security as domain decisions

Actor, resource, state, authority, and policy.

Enforce tenant/object/field authorization server-side

Never trust UI or payload.

Bind evidence to exact versions

Quote, proposal, approval, acceptance, and configuration.

Separate audit from logs and events

Different purpose and controls.

Make privileged operations explicit

JIT, break-glass, preview, approval, and review.

Preserve lineage end to end

Quote to Product and Billing.

Minimize sensitive data

Especially logs, events, and exports.

Design retention and legal hold

Before production incidents/disputes.

Test abuse cases and evidence reconstruction

Not only happy-path permissions.

338. Internal Verification Checklist

Identity and authorization

• Bagaimana tenant dan object-level authorization dipaksakan?
• Which authentication methods and step-up controls exist?
• Are actor and effective principal distinguished?
• Are RBAC, ABAC, relationship, and domain-state rules combined correctly?

Field and data protection

• Apakah price, margin, cost, dan personal data memiliki visibility berbeda?
• Are field read/write/masking rules enforced server-side?
• Are search, cache, event, export, and analytics equally protected?
• What data-classification and encryption policies apply?

Approval and acceptance evidence

• Is approval bound to exact revision, authority, policy, and conditions?
• Is acceptance bound to exact Proposal/Offer checksum?
• How are offline acceptance and multiple signatories evidenced?
• Are replay and signer-authority checks implemented?

Audit

• Audit apa yang immutable dan berapa retention period-nya?
• Is audit distinct from logs and events?
• Are before/after, reason, actor, version, correlation, and timestamps retained?
• How is audit integrity verified?

Traceability and defensibility

• Can every Product/charge trace to accepted Quote and Agreement?
• Are mapping, rule, config, extension, and deployment versions retained?
• Can an evidence package be generated for dispute/audit?
• Are traceability gaps detected and repaired explicitly?

Privileged/support access

• Bagaimana support/admin actions diberi authorization dan traceability?
• Are JIT, case scope, expiry, step-up, and post-review used?
• Can support avoid direct database updates?
• Are bulk corrections dry-run, canaried, and per-item audited?

Privacy and retention

• Are purpose, minimization, retention, deletion, and legal hold governed?
• How are data subject requests handled?
• Are production data copies controlled?
• Can tenant/customer keys be rotated/revoked safely?

Operations and testing

• Are security/audit pipeline failures monitored?
• Are cross-tenant, replay, privilege, export, and evidence tests automated?
• Can DR preserve audit and authorization?
• What historical incidents reveal control gaps?

339. Practical Exercises

Exercise 1 — Authorization matrix

Model subject × action × resource × state × tenant × amount for 30 high-risk commands.

Exercise 2 — Field sensitivity

Classify and authorize price, cost, margin, approval comments, PII, tax, and supplier data.

Exercise 3 — Evidence package

Build a complete package for one accepted Quote through Billing.

Exercise 4 — Privileged recovery

Replace direct SQL repair with case-scoped, approved, audited command.

Exercise 5 — Retention

Design deletion and legal-hold behavior for Quote, Agreement, audit, and Product data.

Exercise 6 — Abuse testing

Test IDOR, self-approval, token replay, unsigned callback, plugin compromise, and bulk export.

340. Part Completion Checklist

You are done if you can:

• separate authentication, authorization, domain validity, and audit;
• enforce tenant/object/field-level access;
• model approval authority and separation of duties;
• protect sensitive commercial and personal data;
• bind approval/acceptance to immutable evidence;
• design tamper-evident audit records;
• preserve forward/backward lineage;
• govern privileged support/admin actions;
• implement retention, legal hold, deletion, and evidence packaging;
• test abuse, replay, isolation, and audit integrity;
• and create an internal security/audit verification backlog.

341. Key Takeaways

1. Authentication does not imply authorization.
2. Tenant, object, field, state, and authority all affect access.
3. Security and audit are domain capabilities.
4. Approval and acceptance must bind exact immutable evidence.
5. Audit is not a debug log.
6. Traceability must connect Quote, Agreement, Order, Product, and Billing.
7. Privileged support access needs JIT, scope, audit, and review.
8. Privacy, retention, and legal hold must be designed together.
9. Tamper evidence and reproducible evidence packages improve defensibility.
10. Internal CSG security, audit, and evidence controls must be verified.

342. References

Conceptual baseline:

• Authentication, RBAC, ABAC, relationship-based authorization, least privilege, separation of duties, JIT access, and privileged access management.
• Multi-tenant isolation, object-level authorization, field-level security, encryption, key management, privacy, retention, and legal hold.
• Immutable/tamper-evident audit, hash chains, digital signatures, trusted timestamps, evidence manifests, and chain of custody.
• Domain-Driven Design authority boundaries, immutable snapshots, decision provenance, and explicit administrative commands.
• Secure API, event, document, extension, supply-chain, logging, and incident-response practices.

These references do not define internal CSG authorization policies, audit storage, retention periods, legal obligations, or support-access procedures.