Given the context of your question, I assume this is a waterfall development environment, as an agile environment deals with this type of question almost by default, as the Product Owner should deal with anything to do with scope.
At a very simple level, a scope change request would be required if "what" is being delivered (i.e. functionality) is changing even in a very small way, whereas "how" it is being delivered (implementation / technology) would not require a scope change request. I would suggest that there should be tolerances on this, however, so that you don't need to raise a change request for changes that are trivial in nature.
Do beware of cumulative trivial changes, however, which may be individually small but in combination they add up to something big enough to need approval. Some devious PMs may even play on this (shock, horror!), by breaking large changes down into lots of small ones, claiming that each is so small that it doesn't have to be treated as a change request and so doesn't need to go through the change approval processes.
However, it isn't always as simple as saying that scope changes only come about as a result of functionality changes. For example, changing the development environment may not change the functionality, but if it could change the look and feel of an application in some way, it may be considered as a scope change by some people.
The other aspect that you don't explicitly mention is where a change leads to a variation in timescale or cost, even if it doesn't change the functionality. In such cases, your sponsor is likely to want a change request unless it is within agreed tolerances. These are not technically "scope" changes (as you are delivering the same outcome - just delivery at a different pace or at a different cost).
Some project offices want change requests even where the change is beneficial (i.e. faster or cheaper), as they need to manage financial or people resources which may become available in such circumstances.
