A scheduled workflow should have only the access needed to perform its defined job. An audit therefore needs to examine more than the person who created the schedule. It should identify who can edit the workflow, which identity runs it, what data and secrets it can reach, which events can trigger it, and who can approve or review its results.
Map the workflow before changing permissions
Record the workflow name, owner, business purpose, schedule, platform, repository or project, execution identity, and destinations it can modify. Include any reusable workflows, third-party actions, service accounts, secrets, cloud roles, notification channels, and deployment environments. Take a snapshot of the current configuration and the last several run results. This provides a recovery reference if a permission change interrupts the job.
Use four access questions for every component: who can view it, who can change it, who can run it outside the schedule, and what authority the runtime receives. A person with no access to the scheduling screen may still be able to alter code that the schedule executes. Conversely, a runtime token may have broad write access even when only a small administrator group can edit the schedule.
Review human and runtime authority separately
For human access, list organization owners, repository administrators, maintainers, environment approvers, and anyone who can edit variables or secrets. Remove departed users, expired contractors, duplicate administrators, and inherited group access that no longer matches a role. Require a named owner and a backup owner so the workflow does not become orphaned.
For runtime access, start with no permissions and add only those the job needs. GitHub's GITHUB_TOKEN guidance says workflows should grant the token the minimum required access and supports setting permissions at workflow or job level. GitHub also warns that an action can access the token through the workflow context even when it is not passed explicitly, so reviewing only visible secret references is not enough.
Check each external credential for scope, expiration, rotation owner, and storage location. Prefer short-lived identities and platform-managed tokens where supported. Never copy secret values into the audit record. Record only the credential name, purpose, scope, owner, and last verified date.
Audit triggers and dependencies
Confirm that the schedule is expected, uses the intended time zone, and runs from the correct branch or configuration version. Review manual triggers, webhooks, repository events, and API entry points that can also start the workflow. GitHub's workflow execution governance guidance describes controls for allowed actors, permitted events, and pinned action dependencies. The exact controls differ by platform, but the audit questions are portable: who can trigger execution, which event types are allowed, and whether dependencies resolve to reviewed code.
List every dependency that executes with the workflow's authority. Prefer immutable versions or reviewed lockfiles where the platform supports them. A friendly action name or mutable tag is not proof that the same code will run next time.
Test reductions safely
Do not remove several permissions at once from a production workflow. Make one bounded change, run the platform's validation, and execute a non-destructive test or an approved manual run. Check logs, outputs, notifications, and downstream records. If the workflow writes data, verify the exact target and ensure the test cannot duplicate a real transaction.
Keep a short decision record for every retained privilege: permission, reason, evidence, owner, and review date. Flag any access that cannot be explained. High-risk exceptions should have an expiration date and explicit approval rather than becoming permanent through silence.
Finish with evidence
The audit is complete when the access map, current owners, runtime permissions, trigger paths, dependency controls, and test results are recorded. Schedule the next review after a role change, credential incident, platform migration, or major workflow edit. The goal is not a permission count of zero; it is a workflow whose authority can be explained line by line and whose removal plan is known if the automation is retired.