При изменении существующего сервиса или добавления нового сервиса требования к сервисному каталогу должны быть определены на стадии развития сервиса как часть выходных результатов разработки. Также должен быть добавлен ожидаемый приоритет и влияние нового сервиса на бизнес-организацию. Эта информация может включать спецификацию SLAs на проективном этапе. Такой подход обычно очень полезен, потому что решение проектируется и разрабатывается согласно SLA, и никак не SLA подгоняется под решение, после его внедрения, это может дорого стоить и требовать дальнейшего развития.
Изменение сервиса должно происходить с принятием во внимание диапазона сервисной информации, зарегистрированной в сервисном каталоге. Например, может казаться, что, хотя сервис и не будет изменен, будет изменен компонент сервиса, используемый в его предоставлении. Поэтому, как часть управления изменениями должен быть выполнен полный анализ воздействия. Потом результаты анализа будут зарегистрированы в сервисном каталоге. Например, конечные пользователи могут использовать такой сервис, как Microsoft Office, удаленно на своем компьютере. Пусть этот сервис не претерпел изменений, а был изменен элемент механизма доставки, например полоса пропускания сети. Это может как затронуть, так и не затронуть работу сервиса, но детали изменения сервисного компонента должны быть зарегистрированы в сервисном каталоге как часть процесса управления изменениями.
Здесь может быть полезно использование другой версии или контроля статуса сервиса в каталоге. Например, сервисы, включенные в каталог, могут определяться по статусу: в разработке, тестировании, в опытной эксплуатации, в промышленной эксплуатации, закрыт, тренинг— в зависимости от потребностей бизнеса и ИТ организации.
