TOGAF And Zachman For Security Architecture

Contractor access should expire when the contract ends. That sounds like a small requirement until you find an application with local accounts, a shared reporting credential, and a background export that keeps running after the directory account is disabled.

Now there are two jobs. You need to understand the access that exists, and you need to organize changes across systems with different owners and constraints. TOGAF and Zachman help with different parts of that work.

The TOGAF Standard, 10th Edition includes a method for developing and changing architecture. The Zachman Framework organizes descriptions of an enterprise. I'd use the first to plan the access change and the second to check whether we've left an important part of the problem undescribed.

Give the change a specific outcome

For the contractor example, “improve identity security” leaves too much room for everyone to agree while imagining a different result. A more useful target is that access expires on a recorded date, renewal requires a named approver, and the departure process handles existing sessions and credentials as well as new logins.

TOGAF's Architecture Development Method provides a cycle for describing the current situation, defining a target, planning the transition, and governing implementation. The amount of documentation should fit the change. A single application doesn't need the same planning package as an enterprise-wide identity migration.

First establish who owns the rule and exceptions. A project manager may know when the contract ends, while the application owner controls the account. If neither is responsible for getting the date into the access system, a new identity product won't resolve the handoff.

Then describe the current paths. Follow an ordinary login, an existing session, an API token, and any scheduled work. Record which system grants each form of access and which event removes it. A directory inventory alone can miss an application account created years earlier.

Make the architecture domains agree

The contractor's end date crosses several kinds of design:

A failure between domains can look deceptively small. The source system may have the correct date, but the account connector might only synchronize names and email addresses. The application may reject new logins while an existing session remains valid. Both are implementation details that determine whether the business requirement works.

The target design needs to account for those gaps. Some applications can use the same automated path. Others may need an integration change, shorter session lifetimes, a manual exception process, or eventual replacement.

Plan a migration people can operate

I would choose one application with an owner who can help test the entire lifecycle. Implement the normal grant, expiry, extension, and revocation paths there before applying the pattern widely.

Dependencies determine the order. An application may need SSO before centrally managed expiry is possible. A response team may need a new permission before it can revoke active sessions. Put that work ahead of the milestone that relies on it.

Governance becomes useful at those decision points. If a release can expire directory membership but cannot revoke existing sessions, record exactly what remains accessible, who accepts the exception, and when it will be addressed. Otherwise the program can report completion while leaving the longest-lived access unchanged.

Use Zachman to find the missing description

Zachman's matrix crosses six questions with six perspectives, from the enterprise's broad scope through detailed design and its operating instances. The questions are what, how, where, who, when, and why.

For contractor access, I'd use them this way:

The perspectives matter because a policy answer and an implementation answer can differ. “All contractor access expires” is an enterprise rule. A nullable expires_at field and a nightly job are one implementation. Someone needs to decide what a missing date means and how much delay the nightly schedule allows.

I wouldn't fill every cell just to complete the matrix. I'd use it to locate the unanswered question that could change the design. If nobody can explain what happens to a token after the person's departure, that needs an answer before another diagram does.

Review the deployed behavior

The first application's acceptance cases should follow the access through to the resource. An expired contractor should fail to open a new session. Test an already-open session separately. Check API tokens and scheduled work using the same identity, and verify that a legitimate extension restores only the intended access.

Observe a failed revocation too. If the target application is unavailable, the job needs to retain the failure and make it visible to the person responsible for resolving it. A successful update in the source directory cannot stand in for a response from every destination.

This is where the two frameworks earn their time. TOGAF helps get the change from an agreed requirement to a managed rollout. Zachman helps expose an unanswered question along the way. The application tests tell you whether the contractor actually lost access.