You may see that in some regulated contexts, but probably not on a per-diagram level. When I worked in aerospace, architectural and design documents were controlled. Prior to new releases entering the formal verification process, the documentation would be exported, given a document number and revision, signed, and then managed by document control. The numbers and revision of all of the documents that apply to a given release were captured as part of the release of the software or the system that the software was embedded on. Each document was scoped to a particular system, subsystem, or component and would contain multiple sections of text and graphics (tables, diagrams, etc.) that pertain to that system.
For most organizations, though, this is probably overkill. It's rarely necessary to have such strict document control. There are plenty of tools that offer version control, change tracking, and even review and approval that don't require all of these concepts. On top of that, using code to represent diagrams (see Structurizr and PlantUML for examples) allows diagrams to be managed in source control systems, with the same branching and tagging schemes as the software they represent.