How we govern: anatomy of a continuous evidence engagement

When a company decides to take compliance seriously, the first question is usually about tools. Which platform should we use? Which integrations should we turn on? Who should own the dashboard? These are reasonable operational questions, but they are the wrong starting point. The more important question is: what does governing a system actually require? What has to happen, in what order, and who has to do it, for the result to hold up when an auditor or a customer asks for proof?

This piece walks through what Bylaw Evidence does when we take on governance of a company's systems. It is a methodology walkthrough, not a case study. The names of specific companies are not the point. The structure of the work is. If you are a compliance lead or a security-focused executive trying to understand what continuous, independent governance looks like in practice — from the first review through to the monthly findings your team actually reads — this is the explanation.

The sequence matters. Governance that starts with connections before it understands policies produces evidence against the wrong controls. Governance that produces beautiful dashboards without an independent record produces confidence without proof. Getting the order right is not a procedural nicety. It is what separates a governance programme that answers "can you prove it?" from one that answers "we believe so."

01 / First review: reading the policies before touching the systems

Every engagement begins with the same first step: reading. Not connecting to systems, not pulling configuration data, not running any checks. Reading the policies, the procedures, the standards, and the prior audit results the company has on hand. This step is non-negotiable because no check against a live system is meaningful until we understand what the policy says the system should be doing.

In practice, this means working through the company's information security policy, its acceptable use policy, its access control procedures, its change management procedures, and any framework-specific documentation — SOC 2 trust service criteria mappings, ISO 27001 Statement of Applicability, HIPAA policies, or GDPR records of processing activities, depending on what applies. We read what exists, not what the team believes exists. There is often a gap.

Alongside policies, we map controls to systems. If the policy says that multi-factor authentication is required for all access to production systems, the next question is: which systems are in scope, and which identity provider controls that requirement? If the policy says that sensitive data must be retained for seven years and deleted on schedule, the question is: where does that data live, and which system enforces the retention and deletion? The control-to-system mapping is what makes it possible to check anything real. Without it, you are monitoring systems you cannot interpret.

Dependencies get traced at this stage too. A change management control in Salesforce may depend on an approval flow that runs through a separate tool. An access control in Microsoft 365 may depend on group membership managed in Okta. Understanding those dependencies before connecting to any system means the checks we build will reflect the actual control architecture, not a simplified version of it that misses how the pieces connect.

02 / Connection: read-pattern access, nothing ingested

Once the policy review is complete and the control-to-system map is in place, we establish connections to the systems in scope. The connection model is the same for every system we govern: least-privilege, read-pattern access. We observe what we need to observe to verify the control. We do not copy records. We do not ingest data. We do not maintain a downstream copy of anything sensitive.

In Salesforce, this means querying access configurations — profiles, permission sets, field-level security, sharing rules — to verify that access controls meet the policy requirements. It does not mean pulling customer records. In Microsoft 365, it means reading policy states — conditional access policies, DLP configurations, retention labels, sharing settings — to verify that the relevant configurations are active. It does not mean reading email or document content. In Okta, it means verifying authentication policies, MFA enforcement, and session controls for the relevant user populations. In AWS, it means reading configuration states — encryption settings, logging status, network access rules — against the relevant accounts and services.

The read-pattern discipline is not a technical limitation. It is an architectural choice with a direct business consequence. An independent governance programme that holds copies of your customer data, your HR records, or your financial information has moved a risk, not eliminated it. The connection model that produces trustworthy evidence is the one that observes at the source and holds only the finding — the confirmation that the control was met or was not, at a specific point in time, against a specific population. That is what we hold. The underlying data stays in the system where it lives.

We hold the finding, not the data. Observing a control at its source and recording what we found is the complete act. The underlying records stay where they live.

Establishing these connections requires working with the company's IT or engineering team. Service accounts need to be provisioned with the right scopes. API credentials need to be managed securely. In most mid-market environments, this work takes a few days. It is not the bottleneck in the engagement. The policy review that precedes it — and the translation work that follows it — is where the substantive time goes.

03 / Translation: from policy sentences to checkable controls

Policy documents are written in natural language. Systems are configured in settings, values, and states. The translation step is where we convert one into the other — turning every relevant policy requirement into a specific, checkable control with an owner, a schedule, and a clear pass/fail criterion.

This work is harder than it looks. A policy that says "access to sensitive data shall be restricted to authorized personnel on a need-to-know basis" is not directly checkable. What systems hold sensitive data? What does "authorized" mean in those systems — which profiles, roles, or permission sets? What population of users is in scope? What does an excess permission look like, and how is it identified? The translation requires answering each of these questions in concrete terms, documented so that the check produces the same result regardless of who runs it.

Each translated control gets an owner. In most cases, that owner is a person at the company — the system administrator, the data protection lead, the security team member responsible for that system. Ownership does not mean the owner runs the check. It means the owner is accountable for the control's state and receives notification when the check finds a problem. Governance does not remove accountability from the company. It provides independent verification that the controls the company is accountable for are actually in place.

Controls are also assigned schedules. Some checks run daily — MFA enforcement, administrative access states, configuration settings where drift is possible and consequential. Others run weekly or monthly — vendor review schedules, access recertification cycles, retention configuration checks. The schedule reflects the risk profile of the control: how quickly could the control fail, and what is the consequence of a gap that persists for a day versus a week? The schedule answers that question in operational terms.

04 / The record: continuous checks, timestamps, and drift caught in place

With policies read, connections established, and controls translated, the continuous record begins. Every check runs on its schedule. Every finding is timestamped. Every result is recorded against the control it verified. When the finding matches the policy requirement, the record reflects that the control was met at that point in time. When the finding does not match — when a configuration has drifted, when an access control has changed, when a retention setting has been altered — the record reflects that too, and it reflects it when it happened, not when the next audit begins.

The timestamp is more significant than it may appear. Point-in-time compliance programmes — the kind that gather evidence for three weeks before the audit window — can only show that the control was in place during the evidence-gathering period. An auditor who understands how those programmes work knows that the evidence they produce says nothing about the other eleven months. A continuous record shows what was true every day, not just the days when someone was watching.

Hashing makes the record reliable. Each finding is hashed at the time it is recorded. The hash is a fixed-length representation of the finding's content — the system, the control, the result, the timestamp. If anything in the record is altered after the fact, the hash does not match. An auditor reviewing the record can verify that what they are reading is what was recorded at the time, not a curated version assembled before the review. This is what independence in a record means, operationally.

Drift is caught when it happens. If a Salesforce administrator modifies a permission set in a way that grants broader access than the policy permits, the next scheduled check on that control surfaces the change. The record notes that the control was passing and is now failing, with the timestamp of the finding. The owner is notified. The company can investigate, remediate, and close the finding. The remediation is also recorded. From that point, an auditor can see not just that the control is passing now, but that it failed on a specific date, was addressed within a specific window, and has been passing since. That narrative is far more credible than a clean snapshot with no history.

05 / What the client sees: a live record and plain-language findings

The output of continuous governance has two forms, and both are designed for people who are not governance specialists.

The live record is available at any time. A compliance lead who needs to answer a customer security questionnaire, respond to an auditor's request, or brief the board on the company's current control state can pull the record without waiting for the next scheduled report or asking a consultant to prepare a presentation. The record shows which controls are being monitored, when each was last checked, what the current status is, and — for any control that has ever had a finding — the full history of that finding, the remediation, and the confirmation that the control is now passing. It is a working document, not a deliverable assembled for a specific audience.

Monthly findings are written in plain language. Not percentage scores, not colour-coded dashboards, not risk matrices that require interpretation. A description of what was checked, what passed, what failed, and what happened about anything that failed. If a configuration drifted and was corrected within twenty-four hours, the finding says that. If a vendor review is overdue and the owner has been notified, the finding says that. If every control in scope passed every check for the month, the finding says that too. The compliance lead can read it, understand it, and share the relevant parts with the people who need to act on them.

The combination — a live record that is always current, and a plain-language summary that arrives monthly — is designed to answer two different questions. The live record answers "what is our control state right now, and can we show someone the history?" The monthly findings answer "what do we need to pay attention to, and have we dealt with it?" A compliance programme that produces only one of these two outputs is either reactive or inaccessible. Both, produced by an independent process, is what a governance engagement looks like when it is working.