01 / 08 of 8
Integrity / rectitude
pronounced gee
Domain: Non-repudiation and ethical conduct
Let your code be true and your actions provable.
Make your actions accountable.
Security depends on knowing who did what, and why.
Authentication establishes identity. Logging records action. Digital signatures establish authorship and integrity. Separation of duties prevents one person from controlling an entire process.
These controls matter because technical authority creates the ability to act without necessarily creating accountability.
The same applies to security decisions. If you approve an exception, accept a risk, disable a control or delay remediation, own the decision.
Logs that can be edited by the people they incriminate.
When Gi is absent, decisions become difficult to trace. Exceptions become permanent. Privileged actions become anonymous. People optimise for immediate outcomes because nobody owns the consequences.
Make the behaviour explicit and repeatable.
Name the decision owner
Every security exception, risk acceptance and material architecture decision has one accountable owner.
Use named privileged access
Eliminate shared administrative identities. Record who elevated, what they accessed and when the privilege ended.
Record security decisions
Keep a decision record for significant changes, exceptions and risk acceptances.
Define ownership
Every critical security control has an accountable owner and an operational owner.
Make escalation explicit
Define who must be informed when a security decision exceeds the team's authority.
Embed the behaviour into processes and ownership.
Time-bound exceptions
Every exception has a reason, risk owner, compensating control and expiry date.
Review consequential changes
Require independent review for high-impact firewall, identity, security-policy and production changes.
Separate approval from execution
Where risk warrants it, the person implementing a sensitive action should not be the sole person approving it.
Preserve audit trails
Ensure administrative actions cannot be altered or deleted by the same identity that performs them.
Formalise risk acceptance
Define who can accept which level of security risk and for how long.
Verify that the behaviour is happening and that it works.
Audit attribution
Periodically test whether consequential administrative actions can actually be attributed to an individual.
Measure stale exceptions
Track exceptions past their review or expiry date.
Review shared accounts
Search for shared, generic and service identities that create attribution gaps.
Test decision records
Sample architecture and security decisions and verify that the stated owner, evidence and approval exist.
Report accountability gaps
Include unattributed privileged activity and overdue ownership actions in security reporting.
Use evidence to improve the behaviour and respond to change.
Learn from accountability failures
Use incidents and near misses to identify where responsibility was unclear.
Reduce manual attribution
Automate identity correlation across PAM, IAM, SIEM and infrastructure platforms.
Reassess authority boundaries
Review whether decision rights still match the organisation's current architecture and operating model.
Challenge risk acceptance
Periodically review recurring accepted risks and determine whether the organisation has normalised them.
Make accountability part of architecture
Design new platforms so that identity, action and evidence remain linked by default.
A business unit asks for a temporary firewall rule to restore an application.
The engineer could implement it and move on. Instead, they record the requester, business justification, destination, expiry date and approving authority.
Six months later, the rule is still there.
The record makes the decision visible. The organisation can identify who accepted the risk and why.
Gi turns a technical change into an accountable decision.
A small infrastructure team shares a domain administrator account because several engineers need emergency access.
There is no reliable attribution when something changes.
The team moves to named privileged accounts with PAM checkout and session logging.
The organisation can now connect an administrative action to a person.
If you cannot attribute an action, you cannot properly investigate it.
A legacy application cannot meet the corporate MFA requirement.
The application owner requests an exception.
Instead of marking it "approved" indefinitely, security records the affected users, the missing control, the risk owner, compensating controls and expiry date.
The exception becomes a decision that somebody owns.
Integrity requires you to own the risk you accept.
An administrator accidentally exposes a storage bucket containing internal information.
There is pressure to fix it quietly.
The administrator reports the mistake immediately.
The organisation can investigate access logs, determine exposure and correct the configuration before the issue becomes an incident involving external parties.
Accountability must survive mistakes.
A security team reports 98% endpoint compliance.
Someone asks how the number was calculated.
The team discovers that thousands of unmanaged devices are excluded from the denominator.
They correct the metric rather than protecting the reported result.
A security metric is only useful when the organisation is willing to expose what it actually measures.
Reading: Tamper-evident logs and cryptographic signatures are how a system stands behind its own actions; the policy control is only partial because policy sets the expectation without producing the evidence.
| Control | Control title | Strength | Why it maps |
|---|---|---|---|
| PR.DS-01 | Confidentiality, integrity, and availability of data at rest | direct | Integrity protection for data at rest is what lets a system stand behind its own recorded actions. |
| GV.PO-01 | Policy for managing cybersecurity risk | partial | Policy sets the expectation of provable, non-repudiable conduct but does not itself produce the evidence. |