I once picked up an assessment where the historical record painted a fairly clear picture of what the third party was expected to do.
The earlier scope described a planned implementation. The service was expected to be introduced into the environment, with access to information that would have mattered from a risk perspective.
If I had treated that historical scope as the current state, the assessment would have been straightforward.
It also would have been wrong.
While revalidating the current scope with the relationship owner, I asked what services were actually in use so I could make sure the assessment captured the relationship as it existed today.
That was when I learned the planned implementation had never happened.
The software had never been installed. The planned work had not progressed into an operational proof of concept. The third party had not accessed the systems, environments, or data contemplated in the earlier scope. Access material created for the proposed work had been removed, and there was no active implementation left to assess.
The original documentation was not necessarily inaccurate.
It was historical.
That distinction matters because third-party records accumulate over time. Intake forms, business descriptions, proposed architecture, contracts, implementation plans, security reviews, and prior assessments may all describe the relationship at different points in its lifecycle.
The problem starts when those points in time are flattened into one permanent version of the truth.
A statement that once meant, “This is what we plan to implement,” can gradually be read as, “This is what we implemented.”
A proposed data flow becomes an assumed data flow.
Expected access becomes assumed access.
The issue in this case was not simply stale documentation. The process had no reliable way to distinguish three different states:
What was proposed?
What actually became operational?
What remains true now?
Once I separated those, the assessment changed.
Instead of treating previously documented data use, system access, and deployment as established facts, I traced each one forward to determine whether the software had ever been installed, whether the implementation had actually begun, whether the anticipated access had ever been granted, whether any data had moved, and whether anything remained active.
The answers materially changed the understanding of the relationship before a single control was evaluated.
That does not make the historical record useless or wrong. It still shows what was contemplated at the time.
But historical scope should be treated as a starting point, not automatically inherited as current state.
The problem appears when the date disappears from the meaning.
If a proposed implementation can remain in a third-party inventory for years without any event forcing the organization to confirm whether it actually happened, that is not only an assessment problem.
It is a process design problem.
The next reviewer should not have to rediscover reality simply because the system never distinguished planned state from operational state.
Historical scope is useful.
It is not a substitute for current reality.
If current scope depends on the next assessor remembering to re-establish historical facts, the process itself has a design gap.
What in today’s scope have you actually re-established, and what are you still carrying forward because it was documented before?