Not In Good Order

Expanded Definition

Not In Good Order, often shortened to NIGO, is a workflow quality term for submissions that fail basic completeness or consistency checks. In identity, legal, financial, and procurement processes, it usually means the package cannot be accepted as-is because required fields, attachments, signatures, versions, or supporting evidence do not line up with the process rule set.

NIGO is not the same as fraud or malicious tampering. It is a validation failure first, although repeated NIGO patterns can expose weak intake controls, poor data capture, or inconsistent ownership. In digital agreement workflows, the distinction matters because a submission can be structurally valid but still NIGO if it does not match the governing checklist or approval path.

Guidance vs consensus: practitioners generally agree on the function of NIGO checks, but organisations differ on where the threshold sits between a correctable omission and a rejectable submission. That boundary is often set by policy, not by technology. For context on machine-related governance that can intersect with digital submission controls, see the OWASP Non-Human Identity Top 10.

Examples and Use Cases

NIGO controls appear wherever a process depends on accurate, complete inputs before downstream review or execution can safely continue.

• A loan application is marked NIGO because income evidence is missing or the uploaded statement does not match the declared applicant name.
• An insurance submission is paused because a required signature page is absent or the policy version referenced in the form is outdated.
• A procurement packet is rejected because the purchase order, approver name, and budget code do not align with the organisation’s workflow rules.
• An onboarding case is routed back because identity documents, contract fields, or supporting attachments are incomplete or inconsistent.
• A digital contract is flagged when an attachment is present, but the attachment checksum, filename, or referenced exhibit does not match the submission record.

The main tradeoff is speed versus assurance: tighter NIGO checks reduce rework and downstream exceptions, but overly rigid checks can create avoidable friction for legitimate users. In practice, the best controls catch mismatches early without turning minor clerical errors into permanent process failure.

Security Implications

NIGO is operationally important because incomplete or inconsistent submissions are a common entry point for avoidable error, duplicate handling, and control bypass. If intake teams accept bad packets too early, downstream reviewers may rely on missing evidence, wrong identifiers, or stale documents, which can lead to incorrect approval, improper denial, or delayed remediation.

The security consequence is usually not a direct exploit but a trust failure in the control chain. A process that cannot reliably distinguish complete from incomplete submissions may also struggle to notice altered documents, swapped attachments, or mismatched authorization evidence. That creates space for weak verification, inconsistent audit trails, and disputes over what was actually submitted.

Practitioner observation: recurring NIGO flags often indicate that the validation rule set is either unclear to submitters or too loosely enforced at intake. When that happens, the organisation absorbs delay at the front end and risk at the back end.

Domain and Governance Relevance

NIGO matters in governance because it defines the boundary between acceptable intake and incomplete request handling. In regulated or high-assurance workflows, that boundary affects who owns correction, when a submission can move forward, and what evidence must exist before the organisation can claim the process was properly followed.

Where NIGO intersects with identity, it becomes more than clerical quality. Missing or inconsistent identity evidence can break assurance, slow account creation, or undermine entitlement decisions. In NHI-adjacent workflows, a similar pattern appears when service account requests, API registrations, or certificate submissions arrive with conflicting ownership, environment, or purpose data.

For NHIMG readers, the key governance point is that NIGO is a control signal, not just a routing label. It should inform process ownership, intake design, and exception handling so the organisation can reduce rejection loops without relaxing the evidence standard that protects trust in the workflow.

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?