With GDAL and other Proj4 based programs it is handy to define the projection by its EPSG code shortcut like "epsg:28992". Shortcut is converted to actual Proj4 projection string by doing a lookup into proj installation files. Unfortunately there are lots of projections with several different projection definitions hanging aroud. Most typical case is that +towgs84 is either missing totally or different parameter sets have been delivered with different Proj4 versions.
For user it can be difficult to control what really happens when epsg code is user. There is a human readable "epsg" file which is stored, for example, to
\proj\SHARE directory. It is possible to edit that file manually and fix the +proj string. Such fix works for example with Mapserver which really reads the string from this file. However, many other programs are generating the +proj string by utilizing other, more native files which are present in the proj installation directories. Actually, the epsg text file is a product from running the native methods for all the supported projections. In practise that means that editing the epsg text does not have any effect for QGIS not GDAL utilities like ogr2ogr.
The most safe way for the user is not to rely on the lookup system utilising the EPSG codes. By defining the projection directly with +proj string, in this case as
"+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 +units=m +no_defs" is explicit and will seldom lead to surprises caused by different Proj4 versions which are installed on the system. Some possibility to error still remains: it is possible that the mathematics behind for example "sterea" is different in different Proj4 versions because of a bug fix or other improvement.
When taking the explicit way it is better to use it on both sides of the conversion. Especially if +towgs84 is added, the target projection must have it defined as well either by +towgs84, +datum, or +nadgrids parameters because datum shift happens only if it is defined on both sides. For examle WGS84-UTM zones have it defined in current Proj4 versions as
# WGS 84 / UTM zone 32N
<32632> +proj=utm +zone=32 +datum=WGS84 +units=m +no_defs <>
whereas European GRS80 based UTM zones use +towgs84 parameters. Notice the use of a transform string "0,0,0,0,0,0,0" which seems to do nothing but it must still be there.
# ETRS89 / UTM zone 32N
<25832> +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>