Not In Good Order

Not In Good Order, or NIGO, describes documents or submissions that are incomplete, inconsistent, or do not match what the process requires. In digital agreement workflows, NIGO checks help catch bad attachments before submission, reducing rework, review delays, and avoidable rejection cycles.

Expanded Definition

NIGO, short for Not In Good Order, is a workflow quality state rather than a security classification. It flags submissions that cannot be processed because required fields, attachments, signatures, metadata, or supporting evidence are missing, inconsistent, or out of sequence. In digital agreement and identity-adjacent workflows, NIGO controls sit at the intake boundary so bad records are rejected before they create downstream rework, approval delays, or audit exceptions. The concept overlaps with validation, but it is narrower than general data quality because it is tied to a specific process rule set and acceptance standard.

In NHI operations, NIGO checks often surface when a service account request, vendor onboarding packet, or access approval lacks the evidence needed for authorization. Definitions vary across vendors, but the practical rule is consistent: the submission must be complete enough to be trusted by the next control. NIGO is best understood as a precondition for orderly processing, not as a substitute for review. For governance context, the NIST Cybersecurity Framework 2.0 reinforces the need for controlled intake and validated execution paths.

The most common misapplication is treating NIGO as a clerical inconvenience, which occurs when teams route incomplete identity or agreement requests into production review instead of blocking them at intake.

Examples and Use Cases

Implementing NIGO rigorously often introduces an upfront friction cost, requiring organisations to weigh faster downstream processing against more disciplined submission review.

• A third-party onboarding packet is rejected because the certificate of authority is missing, preventing an unverified party from receiving access grants.
• A service account request fails NIGO checks because the owning team, expiration date, and intended workload are not documented consistently.
• A digital agreement is held because the signature page is present but the attachment referenced in the contract body was never included.
• A remediation ticket tied to a compromised API key is marked NIGO when the owner cannot prove which system the credential supported, delaying revocation workflow.
• After the kind of credential exposure discussed in the Schneider Electric credentials breach, organisations often tighten intake checks so requests cannot advance without complete ownership and justification.

These examples show that NIGO is not only about formatting. It is about whether a workflow contains enough trustworthy information to move safely into approval, provisioning, or legal acceptance. The NIST Cybersecurity Framework 2.0 supports this kind of disciplined intake as part of broader control execution.

Why It Matters in NHI Security

NIGO matters because weak intake controls let incomplete identity artifacts become operational identities. When service account requests, API key issuance forms, or agreement packages lack required ownership, scope, or expiry data, teams create gaps that later undermine accountability and revocation. That risk is especially acute in environments where NHIs already outnumber human identities by 25x to 50x, and where oversight is often stretched across automation, third parties, and CI/CD pipelines.

NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks, with 77% causing tangible damage. Those figures help explain why NIGO should be treated as an operational control, not paperwork. It is a first-line filter that prevents invalid identity and agreement records from entering systems that assume completeness. The broader NHI governance picture is documented in Ultimate Guide to NHIs, which also frames the importance of lifecycle discipline. Organisations typically encounter the full cost of NIGO only after a bad submission has already triggered a failed audit, a stalled release, or an access incident, at which point the control becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What does good NHI governance look like for audit and compliance purposes?
• Why does Executive Order 14028 matter for IAM teams?
• How can teams tell whether cloud security coverage is actually good enough?
• What should teams do when an AI agent performs approved actions in a harmful order?