EngineeringMechanical EngineeringOperations
SOLIDWORKS Governance, Standards Register & Change Control
Every preceding domain in this series describes decisions. This one is about whether those decisions survive — the staff change, the reorganisation, the year in which nobody has time. A CAD environment degrades through accumulation, not through any single event.
- Group · Operations
- Series · Administration
- Scope · Release-independent
- Reading · 17 min
01 What Holds the Rest Together
Every preceding domain in this series describes decisions. This one is about whether those decisions survive — the staff change, the reorganisation, the year in which nobody has time.
A CAD environment does not degrade through a single event. It degrades through accumulation: a setting changed for one project and never reverted, a library location added for a customer and forgotten, an exception granted to unblock a deadline that becomes the permanent arrangement, an administrator who leaves taking undocumented knowledge with them.
Governance is what converts a set of good decisions into a maintained system. It amounts to three things: a named owner with defined authority, a written record of what has been decided, and a process for changing it deliberately rather than incidentally.
This page describes organisational practice rather than product configuration, so it is release-independent. It assumes the technical practices described elsewhere in this series and addresses how they are sustained.
02 The Administrator Role
CAD administration sits between engineering and IT and is frequently owned by neither, which is the root of a large proportion of the problems described in this series.
IT controls the servers, the domain, the endpoint protection policy, the backup regime and the update cadence. Engineering understands revision control, drawing standards, what the data means and what an approval represents. Neither can administer the environment alone: IT cannot design a workflow, and engineering cannot open a firewall port.
| Area | CAD administrator | IT |
|---|---|---|
| Workstation specification | Defines the requirement by role | Procures, builds, maintains |
| Graphics driver policy | Determines the certified version | Excludes from auto-update; deploys the tested version |
| Endpoint protection exemptions | Specifies paths and file types, justifies | Approves, applies, reviews |
| Deployment image | Builds and configures | Provides the share; may run the distribution |
| Licence administration | Options file, reservation, borrowing policy | Server availability, firewall, monitoring |
| Vault workflow and permissions | Designs and configures | No involvement |
| Vault server platform | Specifies requirement and prerequisites | Builds, patches, monitors |
| Backup | Defines scope and verifies restores | Executes and monitors the regime |
| Standards and templates | Owns entirely | No involvement |
| Upgrade timing | Decides, in consultation | Delivers the platform prerequisites |
In most organisations CAD administration is a fraction of someone's role rather than a full position, and that is workable. What is not workable is leaving it unnamed, because then it is nobody's — and the tasks that suffer are the ones with no immediate deadline: the restore rehearsal, the permission review, the prerequisite register.
Name the person, state the proportion of their time, define their authority, and agree the interface with IT in writing. That single act resolves more than any technical measure in this series.
03 The Standards Register
One document recording every controlled decision about the environment. It is the most valuable artefact an administrator maintains and takes perhaps a day to establish.
Its purpose is not compliance theatre. It answers the questions that otherwise require someone to remember: where is the authoritative template set, why is that setting locked, what version are we on, when was the last restore test, who approved that exception.
Environment baseline
- Release and service pack in service
- Vault client and server versions
- Platform prerequisite versions and retirement dates
- Certified graphics cards and driver versions
- Workstation specification by role
Controlled locations
- Templates, sheet formats, property tab
- Component library and design library
- Material library and drafting standard file
- Administrative image and settings file
- Automation and documentation
- Owner and last review date for each
Configuration decisions
- Locked system options and the reason for each
- Property schema — names, scopes, controlled lists
- Revision scheme and what increments it
- Licence policy: timeouts, reservations, borrowing
- Library numbering and naming conventions
Vault configuration
- Workflow states and their operational meaning
- Transition authorities by role
- Permission groups and what each grants
- Release conditions in force
- Data card variable mapping
Continuity
- Backup scope, schedule and retention
- Restore procedure location
- Date and result of the last restore rehearsal
- Measured recovery time
- Licence serial numbers and reactivation dates
Exceptions and automation
- Every granted exception, its reason, owner and review date
- Automation inventory with owners
- Drafting standard deviations and their justification
- Known issues and workarounds in force
A register that runs to eighty pages will not be updated and will therefore be wrong, which is worse than not having one. Aim for something that can be read in twenty minutes and updated in ten.
Record decisions and locations, not procedures. The procedure for creating an administrative image belongs in vendor documentation; what belongs in the register is where yours lives, what is configured in it, and who owns it.
04 Change Control
Changes to the CAD environment affect everyone who uses it and some things that cannot be reversed. They warrant the same discipline applied to any other production change.
| Change | Reversible | Handling |
|---|---|---|
| System option value | Yes | Update the image, note in the register, tell the team |
| Template revision | For new documents only | Impact assessment, test against real documents, retain the outgoing set |
| Property rename | Only by migration | Treat as a data migration with mapping, script and verification |
| Library numbering convention | Breaks existing references | Effectively permanent. Decide once, with purchasing present |
| Workflow state or transition | Affects files in flight | Test in a separate vault first; time it when little is mid-workflow |
| Permission change | Yes | Change the group, never the individual; record the reason |
| Annual release upgrade | Past the first save | Full planning, validation, verified backup, staged rollout |
| Licence server move | Yes, with effort | Affects every client; borrow beforehand; plan as a fleet change |
An exception granted to unblock a deadline — a setting unlocked, a permission widened, a standard waived — is almost never revisited. It becomes the arrangement, and a year later nobody remembers it was meant to be temporary.
Grant exceptions where they are genuinely warranted, but record every one with its reason, its owner and a review date. The review date is the part that matters, and it is the part usually omitted.
05 The Annual Cycle
A small number of tasks that have no deadline and are therefore never urgent. Putting them on a calendar is what makes them happen.
- Q1Prerequisite and retirement reviewCheck every platform component against its supported range and published retirement milestone. This determines whether the year's upgrade is a software task or an infrastructure programme, and it needs to be known early.
- Q1Hardware certification checkCompare the installed fleet against the certification listing for the release you intend to adopt. A card that has dropped off the list needs lead time.
- Q2Restore rehearsalFull restore to an isolated system. Record the outcome and the duration in the register.
- Q2Permission and exception reviewCompare vault permission groups against the current organisation; review every recorded exception against its review date.
- Q3Upgrade validation and planningAdd-ins, automation, integrations and representative models tested against the target release. Date decided and published.
- Q3Licence usage reviewExamine the usage log, confirm timeouts and reservations are still appropriate, and size any purchase on evidence ahead of renewal.
- Q4Upgrade executionOr deliberately deferred, with the reason recorded. Either is acceptable; drifting into a decision is not.
- Q4Register refreshUpdate the baseline to the verified post-upgrade state, retire obsolete entries, confirm every controlled location still has a named owner.
Licence reactivation and subscription renewal have their own dates and their own consequences for missing them. Diarise them independently with an owner and a reminder, rather than folding them into a quarterly review that might slip.
06 Succession
The test that reveals whether governance is real: could someone else take this over next month?
A successor needs six things, and if any is missing they will spend months rediscovering it — usually while also learning the role and responding to the first incident.
The register
Current, accurate, and covering baseline, locations, decisions and exceptions.
Access
Server access, vault administrative rights, licence portal credentials and reseller contacts — held somewhere durable, not in one person's memory.
The recovery procedure
Written, tested, and stored where it survives the outage it describes.
Automation inventory
What exists, what it does, when it runs, and how to disable it safely.
Entitlement inventory
Serial numbers, counts by product, server identity, reactivation and renewal dates.
The reasoning
Why the workflow is shaped as it is, which exceptions are load-bearing, and which decisions were contested.
Facts can be recovered by investigation. Reasoning cannot. A successor who does not know why a setting is locked will unlock it when someone complains, and rediscover the original problem the hard way.
Record the reason alongside every decision in the register. It is one line per entry, and it is the difference between a register that transfers knowledge and one that transfers only configuration.
07 A Maturity Progression
Most organisations arrive at good practice incrementally. Knowing which step is next is more useful than knowing what perfect looks like.
| Stage | Characterised by | Highest-value next step |
|---|---|---|
| Ad hoc | Individual installations, local templates and libraries, no named owner | Name an owner; establish one shared standards location |
| Standardised | Shared templates and library, deployment image in use, settings locked | Verify backup scope covers the standards location and the image |
| Controlled | Data management in place, workflow reflects the real change process | Rehearse a restore; document the recovery procedure |
| Governed | Register maintained, change control applied, annual cycle observed | Test succession — could someone else run this next month? |
| Integrated | Business system exchange, automation under proper discipline | Review automation economics annually; retire what no longer pays |
The stages build on each other, and skipping produces fragile results. Business system integration on top of an uncontrolled property schema propagates bad data faster. A vault deployed on top of an undefined change process makes the ambiguity permanent. Automation without governance creates dependencies nobody can maintain.
Where several things are wrong at once, the ordering above is a reasonable priority: ownership first, then standards, then control, then governance, then integration.
08 Governance Checklist
- Named owner. A specific person holds CAD administration, with stated time allocation and defined authority.
- IT interface agreed in writing. Who does what across specification, drivers, exemptions, servers, backup and upgrade.
- Standards register exists. Baseline, controlled locations, configuration decisions, vault configuration, continuity, exceptions and automation.
- Reasoning recorded. Every decision in the register carries a one-line justification.
- Every controlled location has an owner and a review date.
- Change control applied. Environment changes assessed for reversibility and handled accordingly.
- Exceptions recorded with review dates. Every waiver has a reason, an owner and a date at which it is reconsidered.
- Annual cycle scheduled. Prerequisite review, certification check, restore rehearsal, permission review, upgrade validation, licence review, register refresh.
- Reactivation and renewal diarised separately. With owners and reminders ahead of the dates.
- Recovery procedure written and tested. Stored where it survives the outage it describes.
- Access recorded durably. Server, vault, licence portal and reseller details held outside one person's memory.
- Succession tested. Someone other than the administrator could take over with the documentation available.
- Maturity stage identified. The next highest-value step known and scheduled.
09 Frequently Asked Questions
We are a small team. Is this level of governance proportionate?
Scale it, but do not skip it. A small team can hold the entire register in a few pages, and the annual cycle might be a morning per quarter. What does not scale down is the consequence: a five-person team that loses its vault or its standards set is affected exactly as severely as a fifty-person one, and typically has less capacity to recover.
The minimum worth having regardless of size is a named owner, a register recording where the controlled things live and why they are configured as they are, a tested restore, and a written recovery procedure. That is perhaps two days of work in total and covers most of the risk.
Engineering and IT disagree about who owns this. How do we resolve it?
Not by assigning it wholly to one side, because neither can do it alone. The productive move is to write down the division explicitly — a table of areas with a named responsible party for each — and have both sides agree it.
The disagreements that persist usually concern a small number of specific items: endpoint protection exemptions, driver update policy, and who may change server configuration. Resolve those three by name, with the reasoning recorded, and the rest generally settles. What must not happen is leaving it unresolved, because the tasks that fall in the gap are the ones with no deadline — and those are the continuity ones.
How do we justify time for governance work with no visible output?
Frame it in terms of specific exposures rather than as good practice. An untested backup is an unknown recovery time for the organisation's entire design record. An undocumented environment is a multi-month gap if the administrator leaves. A missed platform retirement is an unplanned infrastructure programme in the middle of a project year.
Each of those is a concrete risk with a plausible cost, and each is removed by a small amount of scheduled work. A restore rehearsal that produces a measured recovery time is also, incidentally, the answer to a question leadership will eventually ask — which makes it easier to fund the second time.
Where should we start if almost none of this exists?
Three things, in this order. Name an owner, because everything else needs someone to do it. Verify that a restore actually works, because that is the exposure where the consequence is permanent. Then write the register, starting with where the controlled things live and why they are configured as they are.
Everything else in this series can follow incrementally. Those three cost days rather than months and remove the largest exposures. Attempting to implement the whole thing at once generally results in none of it, whereas the first restore rehearsal usually creates the appetite for the rest.
Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.
SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.