Yes and no. Version control is about just that: control of revisions of assets, be they source code text files, images, or even documentation. While software engineers usually put source code and graphical assets (once they receive them) under version control, graphical assets and standards documents are often prepared by non-engineers. In my experience, these people rarely work under version control (though it could be argued that they should).

Another reason why requirements specifications are not often under version control is that they are often not text files (Word documents, spreadsheets, or Google documents are common) and thus versions cannot be compared easily by many version control systems. Yes, modern word processors can intelligently compare different revisions, but sometimes that feature cannot be invoked by the version control system.

In spite of this, there is a natural tendency for people to understand the importance of preserving old versions, and I have seen various ad hoc methods used by non-engineers, like adding revision numbers or dates to the filenames, for instance.

You ask about standards, and I know of no commonly-applied official standards requiring which assets need to be under version control and which do not. This is a managerial and organizational choice, and it varies from place to place. Some enterprises have clear policy around this, using in-house or externally-defined guidelines, or special software tools, others do not.

Although I agree with most of Randall Cook’s answer, I would like to add some additional things.

Your requirements should be under configuration management and be controlled in some way. That is, you should be able to associate a given set of requirements (perhaps captured in a SRS document or a collection of user stories or a database or some other format) to a given software version. For any given software version, you’d probably want to know what the requirements, design, implementation (source code), test cases (test code, scripts, manual procedures), and perhaps even test results are. This aspect of configuration management is called “configuration identification”.

One aspect of configuration management is version control. However, how you implement version control could be different depending on the type of artifact. Source code could be kept in tools that are well-suited to managing software (which is usually text files) – tools like Subversion or git. However, different tools may be necessary to properly version other artifacts. Requirements management tools, such as DOORS, often have change management workflows and support the versioning of requirements. For documents, a content management system may allow you to track versions as well.

As far as standards go, there are standards for configuration management, there are many, some active and some withdrawn or superseded – ANSI, ISO, IEEE, the US Department of Defense, industry specific practices for a number of different industries, and so on. How applicable they are to you depends on a various factors – contractual or regulatory obligations, project size and type, industry, to name a few big ones. They may provide guidance and a starting point for tailoring. Ultimately, though, it’s up to the development organization to define a process that is suitable for their needs.